淘寶的緩存技術

淘寶在很早就開始使用緩存技術了，在2004年的時候，我們使用一個叫做ESI(Edge Side Includes)的緩存（Cache）。在決定采用ESI之前，多隆試用了Java的很多Cache，但都比較重，后來用了Oracle Web Cache，也經常掛掉，Oracle Web Cache也支持ESI，多隆由此發現了ESI這個好東東。ESI是一種數據緩沖/緩存服務器，它提供將Web網頁的部分（這里指頁面的片段）進行緩沖/緩沖的技術及服務。以往的數據緩沖服務器和信息傳送服務器以“頁”為制作單位，復制到數據緩沖服務器中，這用于處理靜態頁面很有效，但在面對 動態內容的時候，就很難得到高效率。在ESI中是部分的緩沖網頁，使用基于XML的標記語言，指定逍遙緩沖的頁面部分。由此，頁面內分為動態地變更部分和靜態的不變部分，只將靜態的部分有效地發送到服務器中。淘寶網的數據雖然是動態產生的，但頁面中的靜態片段也有很多，例如頁面的投、尾，商品詳情頁面的賣家信息等們這些都是從ESI緩存中讀取的。

回顧一下上面幾個版本，1.0版的PHP系統運行了將近一年的時間（2003年5月—2004年1月），服務器由一臺發展到多臺；后來數據庫撐不住了，將MySQL換成了Oracle，引入了搜索引擎

（2004年1月—2004年5月，叫1.1版本）；然后不到半年的時間又把開發語言換成了Java（2004年2月—2005年3月，叫2.0版本），數據服務逐步采用了IOE；隨著數據量和訪問量的增長，我們進行數據分庫、加入緩存、使用CDN（2004年10月—2007年1月，叫2.1版本）。這幾個版本中間有些時間上的重合，因為很多架構的演化并沒有明顯的時間點，它是逐步進化而來的。

在描述2.1版本的時候，我寫的標題是《堅若磐石》，這個“堅若磐石”是因為這個版本終于穩定下來了，在這個版本的系統上，淘寶網運行了兩年多的時間。這期間有很多優秀的人才加入，也開發了很多優秀的產品，例如，商品的類目屬性、支付寶認證系統、招財進寶項目、淘寶旅行、淘寶彩票、淘寶論壇等，甚至在團購網站風起云涌之前，淘寶網在2006年就推出了“團購”的功能。

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

淘寶文件系統——TFS

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

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

2007年之前的圖片存儲架構如下圖所示。

在一次架構師大會上，章文嵩博士總結了幾點商用存儲系統的局限和不足。

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

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

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

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

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

第四，自主研發的系統可在軟件和硬件的多個層次之間不斷優化。

#p#

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

2007年6月，TFS正式上線運營。在生產環境中應用的集群規模達到了200臺PC Server（146GB×6 SAS 15KB Raid5），文件數量達到上億級別；系統部署存儲容量為140TB；實際使用存儲容量為50TB；單臺支持隨機IOPS 200+，流量為3MB/s。

說到TFS的系統架構，首先要描述清楚業務需求，淘寶對圖片存儲的需求大概可以描述如下：文件比較小；并發量高；讀操作遠大于寫操作；訪問隨機；沒有文件修改的操作；要求存儲成本低；能容災，能備份。顯然，應對這種需求時要用分布式存儲系統；由于文件大小比較統一，可以采用專有文件系統；由于并發量高，讀寫隨機性強，需要更少的I/O操作；考慮到成本和備份，需要用廉價的存儲設備；考慮到容災，需要能平滑擴容。

參照GFS并做了大量的優化之后，TFS 1.0版的架構圖如下。

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

在這個系統中：

• 每個Data Server運行在一臺普通的Linux主機上；
• 以Block文件的形式存放數據文件（一個Block的大小一般為Block存儲多份是為了保證數據安全；
• 利用ext3文件系統存放數據文件；
• 磁盤raid5做數據冗余；
• 文件名內置元數據信息，用戶自己保存TFS文件名與實際文件的對照關系，這使得元數據量特別小。

淘寶TFS文件系統在核心設計上最大的取巧在于，傳統的集群系統中元數據只有1份，通常由管理節點來管理，因而很容易成為瓶頸。而對于淘寶網的用戶來說，圖片文件究竟用什么名字來保存他們并不關心，因此，TFS在設計規劃上考慮在圖片的保存文件名上暗藏了 一些元數據信息，例如，圖片的大小、時間、訪問頻次等信息，包括所在的邏輯塊號。而在實際的元數據上，保存的信息很少，因此，元數據結構非常簡單。僅僅只需要一個FileID就能夠準確定位文件在什么地方。由于大量的文件信息都隱藏在文件名中，整個系統完全拋棄了傳統的目錄樹結構，因為目錄樹開銷最大。拿掉后，整個集群的高可擴展性可極大地提高。實際上，這一設計理念和目前業界的“對象存儲”較類似。

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

TFS發布之后，又經歷了多個版本的修改，到1.3版的時候已經比較成熟了。2009年6月，TFS 1.3版本上線，集群規模大大擴展，部署到淘寶的圖片生產系統上，整個系統已經從原有200臺PC服務器擴增至440臺PC服務器（300B×12 SAS 15KB RPM）+30臺PC服務器（600B×12 SAS 15KB RPM )。支持文件數量也擴容至百億級別；系統部署存儲容量為1800TB；當前實際存儲容量為995TB；單臺DataServer支持隨機IOPS900+，流量為15MB+；目前NameServer運行的物理內存是217MB（服務器使用千兆網卡）。

TFS 1.3版本邏輯結構圖如下圖所示。

在TFS 1.3版本中，工程師們重點改善了心跳和同步的性能，最新版本的心跳和同步在幾秒鐘之內就可完成切換，同時進行了一些新的優化，包括元數據存儲在內存中、清理磁盤空間等。

性能上也做了優化，包括如下內容。

• 采用ext4文件系統，并且預分配文件，減少ext3等文件系統淘寶技術這十年數據碎片帶來的性能損耗；
• 單進程管理單塊磁盤的方式，摒除RAID5機制；
• 帶有HA機制的中央控制節點，在安全穩定和性能復雜度之間取得平衡；
• 縮減元數據大小，將更多的元數據加載入內存，提升訪問速度；
• 跨機架和IDC的負載均衡及冗余安全策略；
• 完全平滑擴容。

對于整個圖片服務來說，僅有TFS還是不夠的，整個圖片服務機器的拓撲結構如下圖所示。

整個圖片存儲系統就像一個龐大的服務器，有處理單元、緩存單元和存儲單元。前面已經介紹過后臺的TFS集群文件存儲系統，在TFS前端，還部署著200多臺圖片文件服務器，Apache實現，用于生成縮略圖的運算。

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

圖片文件服務器的前端則是一級緩存和二級緩存，前面還有全局負載均衡的設置，用于解決圖片的訪問熱點問題。圖片的訪問熱點一定存在，重要的是，讓圖片盡量在緩存中命中。目前淘寶網在各個運營商的中心點設有二級緩存，整體系統中心店設有一級緩存，加上全局負載均衡，傳遞到后端TFS的流量就已經非常均衡和分散了，對前端的響應性能也大大提高。據淘寶的緩存策略，大部分圖片都盡量在緩存中命中，如果緩存中無法命中，則會在本地服務器上查找是否存有原圖，并根據原圖生成縮略圖，如果都沒有命中，則會考慮去后臺TFS集群文件存儲系統上調取。因此，最終反饋到TFS集群文件存儲系統上的流量已經被大大優化了。

淘寶網將圖片處理與緩存編寫成基于Nginx的模塊，我們認為，Nginx是目前性能最高的HTTP服務器，代碼清晰，模塊化非常好。淘寶網使用GraphicsMagick進行圖片處理，采用了面向小對象的緩存文件系統，前端有LVS+Haproxy將原圖和其所有的縮略圖請求都調度到同一臺Image Server（圖片服務器）。

在文件定位上，內存用Hash算法做索引，最多一次讀盤。另外會有很多相同的圖片重復上傳上來，去除重復文件也是采用Hash算法來做的。寫盤方式則采用Append方式寫，并采用了淘汰策略FIFO，主要考慮降低硬盤的寫操作，沒有必要進一步提高Cache命中率，因為ImageServer和TFS位于同一個數據中心，讀盤效率還是非常高的。目前淘寶網的TFS已經開源（見code.taobao.org），業界的同仁可以一起使用和完善這個系統。