淘寶文件系統(tǒng)TFS的發(fā)展:商用存儲系統(tǒng)的局限

申請免費試用、咨詢電話：400-8352-114

在講淘寶文件系統(tǒng)TFS之前，先回顧一下上面幾個版本。1.0版的PHP系統(tǒng)運行了將近一年的時間（2003.05-2004.01）；后來數(shù)據(jù)庫變成Oracle之后（2004.01-2004.05，叫1.1版本吧），不到半年就把開發(fā)語言轉換為Java系統(tǒng)了（2004.02-2005.03，叫2.0版本）；進行分庫、加入緩存、CDN之后我們叫它2.1版本（2004.10-2007.01）。這中間有些時間的重合，因為很多架構的演化并沒有明顯的時間點，它是逐步進化而來的。

在描述2.1版本的時候我寫的副標題是“堅若磐石”，這個“堅若磐石”是因為這個版本終于穩(wěn)定下來了，在這個版本的系統(tǒng)上，淘寶網運行了兩年多的時間。這期間有很多優(yōu)秀的人才加入，也開發(fā)了很多優(yōu)秀的產品，例如支付寶認證系統(tǒng)、招財進寶項目、淘寶旅行、淘寶彩票、淘寶論壇等等。甚至在團購網站風起云涌之前，淘寶網在2006年就推出了團購的功能，只是淘寶網最初的團購功能是買家發(fā)起的，達到賣家指定的數(shù)量之后，享受比一口價更低的價格，這個功能看起來是結合了淘寶一口價和荷蘭拍的另一種交易模式，但不幸沒有支撐下去。

在這些產品和功能的最底層，其實還是商品的管理和交易的管理這兩大功能。這兩大功能在2.1版本里面都有很大的變化。商品的管理起初是要求賣家選擇7天到期還是14天到期，到期之后就要下架，必須重新發(fā)布才能上架，上架之后就變成了新的商品信息（ID變過了）。另外如果這個期間內成交了，之后再有新貨，必須發(fā)布一個新的商品信息。這么做有幾個原因，一是參照拍賣商品的時間設置，要在某日期前結束掛牌；二是搜索引擎不知道同樣的商品哪個排前面，那就把掛牌時間長的排前面，這樣就必須在某個時間把老的商品下架掉，不然它老排在前面；第三是成交信息和商品ID關聯(lián)，這個商品如果多次編輯還是同一個ID的話，成交記錄里面的商品信息會變來變去；還有一個不為人知的原因，我們的存儲有限，不能讓所有的商品老存放在主庫里面。這種處理方式簡單粗暴，但還算是公平。不過這樣很多需求都無法滿足，例如同樣的商品，我上一次銷售的時候很多好評都沒法在下一個商品上體現(xiàn)出來；再例如我買過的商品結束后只看到交易的信息，不知道賣家還有沒有再賣了。后來基于這些需求，我們在2006年下半年把商品和交易拆開。一個商家的一種商品有個唯一的ID，上下架都是同一個商品。那么如果賣家改價格、庫存什么的話，已成交的信息怎么處理？那就在買家每交易一次的時候，都記錄下商品的快照信息，有多少次交易就有多少個快照。這樣買賣雙方比較爽了，給系統(tǒng)帶來了什么？存儲的成本大幅度上升了！

存儲的成本高到什么程度呢？數(shù)據(jù)庫方面提到過用了IOE，一套下來就是千萬級別的，那幾套下來就是⋯⋯。另外淘寶網還有很多文件需要存儲，我們有哪些文件呢？最主要的就是圖片、商品描述、交易快照，一個商品要包含幾張圖片和一長串的描述信息，而每一張圖片都要生成幾張規(guī)格不同的縮略圖。在2010年，淘寶網的后端系統(tǒng)上保存著286億個圖片文件。圖片在交易系統(tǒng)中非常重要，俗話說“一張好圖勝千言”、“無圖無真相”，淘寶網的商品照片，尤其是熱門商品，圖片的訪問流量是非常大的。淘寶網整體流量中，圖片的訪問流量要占到90%以上。且這些圖片平均大小為17.45KB，小于8K的圖片占整體圖片數(shù)量61%，占整體系統(tǒng)容量的11%。這么多的圖片數(shù)據(jù)、這么大的訪問流量，給淘寶網的系統(tǒng)帶來了巨大的挑戰(zhàn)。眾所周知，對于大多數(shù)系統(tǒng)來說，最頭疼的就是大規(guī)模的小文件存儲與讀取，因為磁頭需要頻繁的尋道和換道，因此在讀取上容易帶來較長的延時。在大量高并發(fā)訪問量的情況下，簡直就是系統(tǒng)的噩夢。我們該怎么辦？

同樣的套路，在某個規(guī)模以下，采用現(xiàn)有的商業(yè)解決方案，達到某種規(guī)模之后，商業(yè)的解決方案無法滿足，只有自己創(chuàng)造解決方案了。對于淘寶的圖片存儲來說，轉折點在2007年。這之前，一直采用的商用存儲系統(tǒng)，應用NetApp公司的文件存儲系統(tǒng)。隨著淘寶網的圖片文件數(shù)量以每年2倍（即原來3倍）的速度增長，淘寶網后端NetApp公司的存儲系統(tǒng)也從低端到高端不斷遷移，直至2006年，即使是NetApp公司最高端的產品也不能滿足淘寶網存儲的要求。從2006年開始，淘寶網決定自己開發(fā)一套針對海量小文件存儲的文件系統(tǒng)，用于解決自身圖片存儲的難題。這標志著淘寶網從使用技術到了創(chuàng)造技術的階段。

2007年之前的圖片存儲架構如下圖：

章文嵩博士總結了幾點商用存儲系統(tǒng)的局限和不足：

首先是商用的存儲系統(tǒng)沒有對小文件存儲和讀取的環(huán)境進行有針對性的優(yōu)化；其次，文件數(shù)量大，網絡存儲設備無法支撐；另外，整個系統(tǒng)所連接的服務器也越來越多，網絡連接數(shù)已經到達了網絡存儲設備的極限。此外，商用存儲系統(tǒng)擴容成本高，10T的存儲容量需要幾百萬，而且存在單點故障，容災和安全性無法得到很好的保證。

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

1.商用軟件很難滿足大規(guī)模系統(tǒng)的應用需求，無論存儲還是CDN還是負載均衡，因為在廠商實驗室端，很難實現(xiàn)如此大的數(shù)據(jù)規(guī)模測試。

2.研發(fā)過程中，將開源和自主開發(fā)相結合，會有更好的可控性，系統(tǒng)出問題了，完全可以從底層解決問題，系統(tǒng)擴展性也更高。

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

4.自主研發(fā)的系統(tǒng)可在軟件和硬件多個層次不斷的優(yōu)化。

歷史總是驚人的巧合，在我們準備研發(fā)文件存儲系統(tǒng)的時候，google走在了前面，2007年他們公布了GFS（ google file system ）的設計論文，這給我們帶來了很多借鑒的思路。隨后我們開發(fā)出了適合淘寶使用的圖片存儲系統(tǒng)TFS（ taobao file system ）。3年之后，我們發(fā)現(xiàn)歷史的巧合比我們想象中還要神奇，幾乎跟我們同時，中國的另外一家互聯(lián)網公司也開發(fā)了他們的文件存儲系統(tǒng)，甚至取的名字都一樣——TFS，太神奇了！（猜猜是哪家？）

2007年6月，TFS正式上線運營。在生產環(huán)境中應用的集群規(guī)模達到了200臺PC Server（146G*6 SAS 15K Raid5），文件數(shù)量達到上億級別；系統(tǒng)部署存儲容量：140TB；實際使用存儲容量： 50TB；單臺支持隨機IOPS 200+，流量3MBps。

要講TFS的系統(tǒng)架構，首先要描述清楚業(yè)務需求，淘寶對圖片存儲的需求大概可以描述如下：

文件比較??；并發(fā)量高；讀操作遠大于寫操作；訪問隨機；沒有文件修改的操作；要求存儲成本低；能容災能備份。應對這種需求，顯然要用分布式存儲系統(tǒng)；由于文件大小比較統(tǒng)一，可以采用專有文件系統(tǒng)；并發(fā)量高，讀寫隨機性強，需要更少的IO操作；考慮到成本和備份，需要用廉價的存儲設備；考慮到容災，需要能平滑擴容。

參照GFS并做了適度的優(yōu)化之后，TFS1.0版的架構圖如下：

從上面架構圖上看：集群由一對Name Server和多臺Data Server構成，Name Server 的兩臺服務器互為雙機，就是集群文件系統(tǒng)中管理節(jié)點的概念。

在這個架構中：

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

• 以block文件的形式存放數(shù)據(jù)文件（一般64M一個block）

• block存多份保證數(shù)據(jù)安全

• 利用ext3文件系統(tǒng)存放數(shù)據(jù)文件

• 磁盤raid5做數(shù)據(jù)冗余

• 文件名內置元數(shù)據(jù)信息，用戶自己保存TFS文件名與實際文件的對照關系–使得元數(shù)據(jù)量特別小。

淘寶TFS文件系統(tǒng)在核心設計上最大的取巧的地方就在，傳統(tǒng)的集群系統(tǒng)里面元數(shù)據(jù)只有1份，通常由管理節(jié)點來管理，因而很容易成為瓶頸。而對于淘寶網的用戶來說，圖片文件究竟用什么名字來保存實際上用戶并不關心，因此TFS在設計規(guī)劃上考慮在圖片的保存文件名上暗藏了一些元數(shù)據(jù)信息，例如圖片的大小、時間、訪問頻次等等信息，包括所在的邏輯塊號。而在元數(shù)據(jù)上，實際上保存的信息很少，因此元數(shù)據(jù)結構非常簡單。僅僅只需要一個fileID，能夠準確定位文件在什么地方。

由于大量的文件信息都隱藏在文件名中，整個系統(tǒng)完全拋棄了傳統(tǒng)的目錄樹結構，因為目錄樹開銷最大。拿掉后，整個集群的高可擴展性極大提高。實際上，這一設計理念和目前業(yè)界的“對象存儲”較為類似，淘寶網TFS文件系統(tǒng)已經更新到1.3版本，在生產系統(tǒng)的性能已經得到驗證，且不斷得到了完善和優(yōu)化，淘寶網目前在對象存儲領域的研究已經走在前列。

1.3版本的架構見阿里味⋯⋯（編輯注：阿里味，淘寶內網 aliway.com）

作者：趙超