來自:IT168

　　【IT168 專稿】8月27日下午，在IT168系統架構師大會儲存與系統架構分論壇上，淘寶網技術委員會主席，淘寶網核心工程師章文嵩向我們詳細介紹了淘寶網圖片處理與儲存系統的架構。章文嵩博士的演講日程包括了淘寶的整個系統架構、淘寶圖片儲存系統架構，淘寶網獨立開發的TFS叢集檔案系統，前端CDN系統以及淘寶網在節能伺服器方面的應用和探索。

　　本文側重介紹淘寶網後臺的圖片儲存系統架構、包括TFS叢集檔案系統，以及前端處理伺服器架構。

　　解決海量併發小檔案的系統噩夢

　　對於淘寶網這型別訪問量極高的電子交易網站來說，對圖片系統的要求和日常的照片分享完全不在一個級別。日常照片分享往往集中在幾個有限的親朋好友之間，訪問量不會特別高，而淘寶網商鋪中的商品照片，尤其是熱門商品，圖片的訪問流量其實是非常大的。而且對於賣家來說，圖片遠勝於文字描述，因此賣家也格外看重圖片的顯示質量、上傳時間、訪問速度等等問題。根據淘寶網的流量分析，整個淘寶網流量中，圖片的訪問流量會佔到90%以上，而主站的網頁則佔到不到10%。

淘寶網電子商城首頁截圖，淘寶網的後端系統上儲存著286億多個圖片檔案，淘寶網整體流量中，圖片的訪問流量要佔到90%以上。且這些圖片平均大小為17.45KB，小於8K的圖片佔整體圖片數量61%，整體系統容量的11%

　　與此同時，這些圖片的儲存與讀取還有一些頭疼的要求：例如，這些圖片要求根據不同的應用位置，生成不同大小規格的縮圖。考慮到多種不同的應用場景以及改版的可能性，一張原圖有可能需要生成20多個不同尺寸規格的縮圖。

　　淘寶整體圖片儲存系統容量1800TB（1.8PB），已經佔用空間990TB（約1PB）。儲存的圖片檔案數量達到286億多個，這些圖片檔案包括根據原圖生成的縮圖。平均圖片大小是17.45K；8K以下圖片佔圖片數總量的61%，佔儲存容量的11%。

　　分析自主研發和商用系統的經濟效益

　　淘寶網成立於2003年，在整個系統的構建和規劃上也做過相當多的嘗試和探索。

　　下圖是淘寶網2007年之前的圖片儲存系統。淘寶網之前一直採用的商用儲存系統，應用NetApp公司的檔案儲存系統。隨著淘寶網的圖片檔案數量以每年2倍(即原來3倍)的速度增長，淘寶網後端NetApp公司的儲存系統也從低端到高階不斷遷移，直至2006年，即時是NetApp公司最高階的產品也不能滿足淘寶網儲存的要求。

淘寶網2007年以前的圖片儲存系統架構圖，由於淘寶網圖片速度已每年2倍的速度增長，商用系統已經完全不能滿足其儲存需求，目前淘寶網採用自主研發的TFS叢集檔案系統來解決海量小圖片的讀取和訪問問題。

　　章文嵩博士在這裡總結了幾點商用儲存系統的侷限和不足：

　　首先是商用的儲存系統沒有對小檔案儲存和讀取的環境進行有針對性的優化；其次，檔案數量大，網路儲存裝置無法支撐；另外，整個系統所連線的伺服器也越來越多，網路連線數已經到達了網路儲存裝置的極限。此外，商用儲存系統擴容成本高，10T的儲存容量需要幾百萬￥，而且存在單點故障，容災和安全性無法得到很好的保證。

　　談到在商用系統和自主研發之間的經濟效益對比，章文嵩博士列舉了以下幾點經驗：

　　1. 商用軟體很難滿足大規模系統的應用需求，無論儲存還是CDN還是負載均衡，因為在廠商實驗室端，很難實現如此大的資料規模測試。

　　2. 研發過程中，將開源和自主開發相結合，會有更好的可控性，系統出問題了，完全可以從底層解決問題，系統擴充套件性也更高。

自主研發和採用商用系統的經濟效益對比

　　3. 在一定規模效應基礎上，研發的投入都是值得的。上圖是一個自主研發和購買商用系統的投入產出比對比，實際上，在上圖的交叉點左邊，購買商用系統都是更加實際和經濟性更好的選擇，只有在規模超過交叉點的情況下，自主研發才能收到較好的經濟效果，實際上，規模化達到如此程度的公司其實並不多，不過淘寶網已經遠遠超過了交叉點。

　　4. 自主研發的系統可在軟體和硬體多個層次不斷的優化。

　　TFS 1.0版本的叢集檔案系統

　　從2006年開始，淘寶網決定自己開發一套針對海量小檔案儲存難題的檔案系統，用於解決自身圖片儲存的難題。到2007年6月，TFS(淘寶檔案系統，Taobao File System)正式上線運營。在生產環境中應用的叢集規模達到了200臺PC Server(146G*6 SAS 15K Raid5)，檔案數量達到上億級別；系統部署儲存容量: 140 TB；實際使用儲存容量: 50 TB；單臺支援隨機IOPS 200+，流量3MBps。

淘寶叢集檔案系統TFS 1.0第一版的邏輯架構，TFS最大的特點就是將一部分元資料隱藏到圖片的儲存檔名上，大大簡化了元資料，消除了管理節點對整體系統效能的制約，這一理念和目前業界流行的“物件儲存”較為類似。

　　圖為淘寶叢集檔案系統TFS 1.0第一版的邏輯架構：叢集由一對Name Server和多臺Data Server構成，Name Server的兩臺伺服器互為雙機，就是叢集檔案系統中管理節點的概念。

　　• 每個Data Server執行在一臺普通的Linux主機上

　　• 以block檔案的形式存放資料檔案(一般64M一個block)

　　• block存多份保證資料安全

　　• 利用ext3檔案系統存放資料檔案

　　• 磁碟raid5做資料冗餘

　　• 檔名內建元資料資訊，使用者自己儲存TFS檔名與實際檔案的對照關係–使得元資料量特別小。

　　淘寶TFS檔案系統在核心設計上最大的取巧的地方就在，傳統的集群系統裡面元資料只有1份，通常由管理節點來管理，因而很容易成為瓶頸。而對於淘寶網的使用者來說，圖片檔案究竟用什麼名字來儲存實際上使用者並不關心，因此TFS在設計規劃上考慮在圖片的儲存檔名上暗藏了一些元資料資訊，例如圖片的大小、時間、訪問頻次等等資訊，包括所在的邏輯塊號。而在元資料上，實際上儲存的資訊很少，因此元資料結構非常簡單。僅僅只需要一個fileID，能夠準確定位檔案在什麼地方。

　　由於大量的檔案資訊都隱藏在檔名中，整個系統完全拋棄了傳統的目錄樹結構，因為目錄樹開銷最大。拿掉後，整個叢集的高可擴充套件性極大提高。實際上，這一設計理念和目前業界的“物件儲存”較為類似，淘寶網TFS檔案系統已經更新到1.3版本，在生產系統的效能已經得到驗證，且不斷得到了完善和優化，淘寶網目前在物件儲存領域的研究已經走在前列。

　　TFS 1.3版本的叢集檔案系統

　　到2009年6月，TFS 1.3版本上線，叢集規模大大擴充套件，部署到淘寶的圖片生產系統上，整個系統已經從原有200臺PC伺服器擴增至440臺PC Server(300G*12 SAS 15K RPM)+30臺PC Server (600G*12 SAS 15K RPM)。支援檔案數量也擴容至百億級別；系統部署儲存容量：1800TB(1.8PB)；當前實際儲存容量：995TB；單臺Data Server支援隨機IOPS 900+，流量15MB+;目前Name Server執行的實體記憶體是217MB(伺服器使用千兆網絡卡)。

TFS 1.3版本邏輯結構圖

　　圖為TFS1.3版本的邏輯結構圖，在TFS1.3版本中，淘寶網的軟體工作組重點改善了心跳和同步的效能，最新版本的心跳和同步在幾秒鐘之內就可完成切換，同時進行了一些新的優化：包括元資料存記憶體上，清理磁碟空間，效能上也做了優化，包括：

• 完全扁平化的資料組織結構，拋棄了傳統檔案系統的目錄結構。
• 在塊裝置基礎上建立自有的檔案系統，減少EXT3等檔案系統資料碎片帶來的效能損耗。
• 單程序管理單塊磁碟的方式，摒除RAID5機制。
• 帶有HA機制的中央控制節點，在安全穩定和效能複雜度之間取得平衡。
• 儘量縮減元資料大小，將元資料全部載入入記憶體，提升訪問速度。
• 跨機架和IDC的負載均衡和冗餘安全策略。
• 完全平滑擴容。

　　在後面“圖片伺服器部署與快取”一節中詳細介紹了淘寶網整個圖片處理系統的拓撲圖。我們可以看到，TFS在淘寶的部署環境中前端有兩層緩衝，到達TFS系統的請求非常離散，所以TFS內部是沒有任何資料的記憶體緩衝的，包括傳統檔案系統的記憶體緩衝也不存在。

　　TFS主要的效能引數不是IO吞吐量，而是單臺PCServer提供隨機讀寫IOPS。由於大家硬體型號不同，當然也是因為一些技術保密的原因，淘寶網很難給出一個參考值來說明效能。但基本上可以達到單塊磁碟隨機IOPS理論最大值的60%左右，整機的輸出隨盤數增加而線性增加。

　　開發中的TFS2.0與開源TFS

　　TFS 2.0已經在開發過程中，主要解決的問題是大檔案儲存的難題。TFS最早開發的時候針對小檔案頻繁併發讀取的難題而開發，設計的塊大小是64MB，意味著每個檔案小於64MB，這對於一般的圖片儲存來說完全足夠用了，但對於大檔案儲存還有一些瓶頸。

　　TFS 2.0將重點針對大檔案跨越塊的儲存進行優化。此外，還包括SSD、SAS硬碟不同硬碟特性的應用優化。根據淘寶網的資料資料，SSD的儲存成本大約是20￥每GB左右，SAS硬碟的儲存成本約在5-6￥每GB，SATA盤的每GB成本不到1￥。隨著對應用效能的要求提升，應用SSD是未來的趨勢，針對不同硬碟的存取特性進行優化是十分必要的。

　　此外，章文嵩宣佈，TFS將在9月份完全開源，完全開源則意味著淘寶網將提供所有的原始碼，開源版本的TFS將與淘寶網線上應用的系統完全一致。

　　圖片伺服器部署與快取

淘寶網圖片儲存與處理系統全域性拓撲，圖片伺服器前端還有一級和二級快取伺服器，儘量讓圖片在快取中命中，最大程度的避免圖片熱點，實際上後端到達TFS的流量已經非常離散和平均

　　上圖為淘寶網整體系統的拓撲圖結構。整個系統就像一個龐大的伺服器一樣，有處理單元、快取單元和儲存單元。前面已經詳細介紹過了後臺的TFS叢集檔案儲存系統，在TFS前端，還部署著200多臺圖片檔案伺服器，用Apatch實現，用於生成縮圖的運算。

　　這裡需要補充一點，根據淘寶網的縮圖生成規則，縮圖都是實時生成的。這樣做的好處有兩點：一是為了避免後端圖片伺服器上儲存的圖片數量過多，大大節約後臺儲存空間的需求，淘寶網計算，採用實時生成縮圖的模式比提前全部生成好縮圖的模式節約90%的儲存空間，也就是說，儲存空間只需要後一種模式的10%；二是，縮圖可根據需要實時生成出來，更為靈活。

　　圖片檔案伺服器的前端則是一級快取和二級快取，前面還有全域性負載均衡的設定，解決圖片的訪問熱點問題。圖片的訪問熱點一定存在，重要的是，讓圖片儘量在快取中命中。目前淘寶網在各個運營商的中心點設有二級快取，整體系統中心店設有一級快取，加上全域性負載均衡，傳遞到後端TFS的流量就已經非常均衡和分散了，對前端的響應效能也大大提高。

　　根據淘寶的快取策略，大部分圖片都儘量在快取中命中，如果快取中無法命中，則會在本地伺服器上查詢是否存有原圖，並根據原圖生成縮圖，如果都沒有命中，則會考慮去後臺TFS叢集檔案儲存系統上調取，因此，最終反饋到TFS叢集檔案儲存系統上的流量已經被大大優化了。

　　淘寶網將圖片處理與快取編寫成基於Nginx的模組，淘寶網認為Nginx是目前效能最高的HTTP伺服器(使用者空間)，程式碼清晰，模組化非常好。淘寶網使用GraphicsMagick進行圖片處理，採用了面向小物件的快取檔案系統，前端有LVS+Haproxy將原圖和其所有縮圖請求都排程到同一臺Image Server。

　　檔案定位上，記憶體用hash演算法做索引，最多一次讀盤。寫盤方式則採用Append方式寫，並採用了淘汰策略FIFO，主要考慮降低硬碟的寫操作，沒有必要進一步提高Cache命中率，因為Image Server和TFS在同一個資料中心，讀盤效率還是非常高的。

　　演講人簡介

　　章文嵩博士是淘寶網的研究員，主要負責基礎核心軟體研發、推進網路軟硬體方面的效能優化、搭建下一代高可擴充套件低碳低成本淘寶電子商務基礎設施。他也是開放原始碼及Linux核心的開發者，著名的Linux叢集專案--LVS (Linux Virtual Server)的創始人和主要開發人員，LVS叢集程式碼已在Linux 2.4和2.6的官方核心中。在設計和架構大型系統、系統軟體開發、Linux作業系統、系統安全和軟體開發管理上有著豐富的經驗。他一直在自由軟體的開發上花費時間，並以此為樂。

轉載於:https://blog.51cto.com/xiaoyaosr/550483