新浪微博圖床架構解析

可以先看一下 http://c.blog.sina.com.cn/profile.php?blogid=a466bf9189000rsw 新浪微博官方發出來的文章。以下我們來解析一下如何構建高可用的圖片儲存系統 以滿足現在日益增長的圖片量，保證系統穩定高效的執行。

 

微博圖床系統分析

 

圖床系統 ，我們先來分析下基於此類系統的一個特性

特性：

1. 1.       小檔案數量巨多，通常為幾十k到幾百k不等。

                                       i.              通常我們認為大小在1MB以內的檔案稱為小檔案，百萬級數量及以上稱為海量，由此量化定義海量小檔案問題 稱為LOSF

1. 2.       頻繁的讀寫操作
2. 3.       大規模的圖片處理

基本上可以簡單的描述為 在圖片數量巨大且讀寫操作頻繁的時候，圖片的upload或者download出現了高延時，嚴重影響了使用者的使用 更有甚者 導致伺服器崩潰。

 

造成這些現象的主要原因是什麼 呢？

 

先來了解一下傳統的圖片儲存架構

 

 

依靠cdn來解決圖片訪問問題，同時儘量使之在快取中命中

採用負載均衡

         負載均衡(Load Balance)將大量的併發訪問或資料流量分擔到多臺節點裝置上分別處理，減少使用者等待響應的時間提高處理能力，負載均衡建立在現有網路結構之上，它提供了一種廉價、有效、透明的方法，來擴充套件網路裝置和伺服器的頻寬、增加吞吐量、加強網路資料處理能力、提高網路的靈活性和可用性。

尤其是全域性負載均衡，能大大提高使用者的訪問速度

把各地的使用者對於資源的訪問，根據內容有無，伺服器負載，網路頻寬和速度，將請求導向到不同的伺服器叢集進行服務。

在使用者量和效能需求的情況下，只能新增高階的裝置。

 

這樣的儲存架構在圖片日益增多的情況下，會產生如下的問題：

1. 1.       從設計上看，擴充套件性差，成本過高，很難滿足容災需求。

從硬體及軟體角度看：衡量儲存系統的標準：IOPS和資料吞吐量 (單位時間內成功傳輸的資料)

1. 2.       快取資料量大
2. 3.       大量的磁碟定址
3. 4.       大量的後設資料操作
4. 5.       單個目錄的檔案數限制
5. 6.       網路開銷大

 

快取資料量大：增加伺服器時間長 ，重啟伺服器時間長。

快取中一般為熱點檔案，在資料量巨大的時候快取命中率會下降，從而導致會頻繁的從檔案伺服器查詢並下載檔案。

 

大量的磁碟定址：影響磁碟的關鍵因素是磁碟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