來自: 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操作系統、系統安全和軟件開發管理上有着豐富的經驗。他一直在自由軟件的開發上花費時間，並以此爲樂。