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

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

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

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

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

　　2007年之前的圖片存儲架構(gòu)如下圖：

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

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

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

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

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

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

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

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

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

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

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

　　參照 GFS 并做了適度的優(yōu)化之后，TFS 1.0 版的架構(gòu)圖如下：

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

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

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

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

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

　　1.3 版本的架構(gòu)見阿里味（阿里巴巴內(nèi)網(wǎng)）⋯⋯