新浪微博图床架构解析
可以先看一下?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