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

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

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

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

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

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

　　章文嵩博士總結了幾點商用存儲系統的局限和不足:

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

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

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

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

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

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

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

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

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

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

　　參照 GFS 并做了適度的優化之后，TFS 1.0 版的架構圖如下：

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

　　在這個架構中：
　　• 每個 Data Server 運行在一臺普通的 Linux 主機上
　　• 以 block 文件的形式存放數據文件(一般64M一個block )
　　• block 存多份保證數據安全
　　• 利用 ext3 文件系統存放數據文件
　　• 磁盤 raid5 做數據冗余
　　• 文件名內置元數據信息，用戶自己保存 TFS 文件名與實際文件的對照關系 – 使得元數據量特別小。

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

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

　　在 TFS 上線之前，淘寶網每個商品只允許上傳一張圖片，大小限定在 120K 之內，在商品詳情里面的圖片必須使用外站的服務。那時侯發布一件商品確實非常麻煩，筆者曾經想賣一臺二手電腦，先把照片上傳到 Google 相冊，在發布到淘寶網之后發現 Google 相冊被墻了，我的圖片別人看不到，當時郁悶的不行。TFS 上線后，商品展示圖片開放到 5 張，商品描述里面的圖片也可以使用淘寶的圖片服務，到現在為止，淘寶網給每個用戶提供了 1G 的圖片空間，這下大家都滿足了。技術和業務就是這么互相用力的推動著，業務滿足不了的時候，技術必須創新，技術創新之后，業務有了更大的發展空間。 

　　1.3 版本的架構見阿里味（阿里巴巴內網）⋯⋯