新浪微博图床架构解析
可以先看一下?http://c.blog.sina.com.cn/profile.php?blogid=a466bf9189000rsw?新浪微博官方發出來的文章。以下我們來解析一下如何構建高可用的圖片存儲系統 以滿足現在日益增長的圖片量，保證系統穩定高效的運行。
?
微博圖床系統分析
?
圖床系統?，我們先來分析下基于此類系統的一個特性
特性：
?????????????????????????????????????? i.??????????????通常我們認為大小在1MB以內的文件稱為小文件，百萬級數量及以上稱為海量，由此量化定義海量小文件問題?稱為LOSF
基本上可以簡單的描述為?在圖片數量巨大且讀寫操作頻繁的時候，圖片的upload或者download出現了高延時，嚴重影響了用戶的使用?更有甚者?導致服務器崩潰。
?
造成這些現象的主要原因是什么?呢？
?
先來了解一下傳統的圖片存儲架構
?
?
依靠cdn來解決圖片訪問問題，同時盡量使之在緩存中命中
采用負載均衡
?????????負載均衡(Load Balance)將大量的并發訪問或數據流量分擔到多臺節點設備上分別處理，減少用戶等待響應的時間提高處理能力，負載均衡建立在現有網絡結構之上，它提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
尤其是全局負載均衡，能大大提高用戶的訪問速度
把各地的用戶對于資源的訪問，根據內容有無，服務器負載，網絡帶寬和速度，將請求導向到不同的服務器集群進行服務。
在用戶量和性能需求的情況下，只能添加高端的設備。
?
這樣的存儲架構在圖片日益增多的情況下，會產生如下的問題：
從硬件及軟件角度看：衡量存儲系統的標準：IOPS和數據吞吐量 (單位時間內成功傳輸的數據)
?
緩存數據量大：增加服務器時間長?，重啟服務器時間長。
緩存中一般為熱點文件，在數據量巨大的時候緩存命中率會下降，從而導致會頻繁的從文件服務器查找并下載文件。
?
大量的磁盤尋址：影響磁盤的關鍵因素是磁盤I/O服務時間，即磁盤完成一個I/O請求所花費的時間，它由尋道時間、旋轉延遲和數據傳輸時間三部分構成。因此可以計算磁盤的IOPS= 1000 ms/ (Tseek + Troatation + Ttransfer)，如果忽略數據傳輸時間，理論上可以計算出磁盤的最大IOPS。當I/O訪問模式為隨機讀寫時，尋道時間和旋轉延遲相對于順序讀寫要明顯增加，磁盤IOPS遠小于理論上最大值。定義有效工作時間Pt=磁盤傳輸時間/磁盤I/O服務時間，由此可知隨機讀寫單個文件效率要低于連續讀寫多個文件。
大量的元數據操作：當小文件數量急劇增加時，對大量元數據的操作會嚴重影響系統的性能。
單個目錄文件數：以磁盤為存儲介質的單機文件系統（如ext4、xfs等），文件都是以目錄樹結構來組織的，當文件數很多時，目錄內的文件數會很多、目錄層次也會變深，索引時間長，一次路徑名查找可能需要多次磁盤IO，并且單機無法存儲。
網絡開銷增大：增加了RPC網絡通信開銷，擴大了小文件訪問延時?。
?
問題分析出來了?那么如何解決呢？
先了解下現在各大互聯網公司的解決方案：
淘寶的TFS
?????????TFS（Taobao File System）是一個高可擴展、高可用、高性能、面向互聯網服務的分布式文件系統，主要針對海量的非結構化數據，它構筑在普通的Linux機器集群上，可為外部提供高可靠和高并發的存儲訪問。TFS為淘寶提供海量小文件存儲，通常文件大小不超過1M，滿足了淘寶對小文件存儲的需求，被廣泛地應用 在淘寶各項應用中。
Facebook Haystacks
Haystack，一個為高效存儲和檢索billion級別圖片而優化定制的對象存儲系統。
微博 notfs ?
新浪自主研發的notfs用戶態小文件存儲系統，以解決傳統文件系統目錄索引查詢帶來的額外的磁盤IO開銷，吞吐是傳統方案的3倍，并能獲得一致的常量低延遲訪問。
Twitter Blobstore
Blobstore是由Twitter開發的一個低成本和可擴展的的存儲系統，可以用來存儲圖片以及其他的二進制對象（稱為“blob”）。在開始構建Blobstore時，Twitter有三個設計目標：
低成本：可以大大減少花費在添加圖片到Tweet中的時間和成本。
高性能：圖片延遲保持在幾十毫秒之內，同時保證每秒上千萬張吞吐量的圖片請求。
易于操作：隨著Twitter基礎設施的不斷增長，能夠擴展操作開銷。
?
解決上述問題?我們需要優化或者說是解決以下的點：
架構上：采用分布式存儲架構
硬件優化：使用速度更快的SSD作為全部或部分存儲介質，采用處理能力更強或更多的CPU，配置更大的內存，采用延遲更小、帶寬更高的網絡設備優化網絡傳輸效率等等。
?????????優點是最行之有效也是做簡單的做法。
?????????????????? ?缺點是成本過大，高高高富帥公司。
元數據優化：在文件命中蘊含部分或全部的元數據信息，減少對元數據的訪問同時有效的減少目錄的深度?減少的I/O操作，在添加Cache系統對元數據緩存，采用hash等高效的數據結構。
小文件合并存儲：此類問題的主要解決方案，
?????????它通過多個邏輯文件共享同一個物理文件，將多個小文件合并存儲到一個大文件中，實現高效的小文件存儲
?????????首先，減少了大量元數據。通過將大量的小文件存儲到一個大文件中，從而把大量的小文件數據變成大文件數據，減少了文件數量，從而減少了元數據服務中的元數據數量，提高了元數據的檢索和查詢效率，降低了文件讀寫的I /O操作延時，節省了大量的數據傳輸時間。
其次，增加了數據局部性，提高了存儲效率。磁盤文件系統或者分布式文件系統中，文件的元數據和數據存儲在不同位置。采用合并存儲機制后，小文件的元數據和數據可以一并連續存儲大文件中，這大大增強了單個小文件內部的數據局部性。小文件合并過程中，可以利用文件之間的空間局部性、時間局部性以及關聯，盡量將可能連續訪問的小文件在大文件中進行連續存儲，增強了小文件之間的數據局部性。這直接降低了磁盤上隨機I/O比率，轉換成了順序I/O，能夠有效提高I/O讀寫性能。另外，小文件單獨存儲會形成外部和內部碎片，而合并存儲后存儲碎片將大大降低，這極大提高了LOSF存儲效率。
再次，簡化了I/O訪問流程。
?
此外還要解決容災，負載，擴容等實際問題。
??像微博的圖床系統就采用的跨IDC的分布式存儲系統
微博圖床平臺是一個跨IDC的大規模分布式對象存儲系統，也是新浪第一個實現跨IDC多主寫入容災，以實現全網服務可用性的技術平臺。跨IDC多主寫入意味著任意一個數據中心故障，就可以快速切換容災至其他可用數據中心。我們使用了一種內部叫做BOR的基于業務對象的復制協議，內部的最終一致性與實時代理結合，以實現用戶端的強一致性。
?
淘寶是多機房容災?原理都差不多。
?
小文件的存儲解決之后，對于圖床系統最后一個需要解決的問題就是壓縮。
?
圖片壓縮的過程是一個CPU和內存消耗性的耗時邏輯
?
微博的解決方案?微博發出的文章中有
http://c.blog.sina.com.cn/profile.php?blogid=a466bf9189000rsw
淘寶的解決方案 是在下載環節來進行壓縮圖片
?
部署imageServer集群，做圖片壓縮處理
若請求圖片在Cache中，直接發送；Cache未命中，本地有原圖根據本地原圖處理并緩存；本地無，則從TFS取得原圖 處理并緩存。
?
淘寶實時生成縮略圖的好處：一是節省后端存儲?減輕壓力?二是可以隨時生成?動態靈活。
?
分析到此結束，當然怎么應用到自家的系統中?還需要根據自己的系統來定制什么需要什么不需要。
?謝謝！
文章 參考了 一些小文件存儲的博文，其中也引用了些內容?http://blog.csdn.net/liuaigui/article/details/9981135
總結
以上是生活随笔為你收集整理的新浪微博图床架构解析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： JC-9、pillow的使用
- 下一篇： RabbitMQ初步到精通-第十章-Ra