Facebook目前存儲了2600億張照片，總大小為20PB，通過計算可以得出每張照片的平均大小為20PB/260GB，約為80KB。用戶每周新增照片數為10億（總大小為60TB），平均每秒新增的照片數為10_{9}/7/40000（按每天40000s計），約為每秒3500次寫操作，讀操作峰值可以達到每秒百萬次。

Facebook相冊后端早期采用基于NAS的存儲，通過NFS掛載NAS中的照片文件來提供服務。后來出于性能和成本考慮，自主研發了Facebook Haystack存儲相冊數據。

系統架構

Facebook Haystack的思路與TFS類似，也是多個邏輯文件共享一個物理文件。Haystack架構及讀請求處理流程如圖4-6所示。

Haystack系統主要包括三個部分：目錄（Directory）、存儲（Store）以及緩存（Cache）。Haystack存儲是物理存儲節點，以物理卷軸（physical volume）的形式組織存儲空間，每個物理卷軸一般都很大，比如100GB，這樣10TB的數據也只需100個物理卷軸。每個物理卷軸對應一個物理文件，因此，每個存儲節點上的物理文件元數據都很小。多個物理存儲節點上的物理卷軸組成一個邏輯卷軸（logical volume），用于備份。Haystack目錄存放邏輯卷軸和物理卷軸的對應關系，以及照片id到邏輯卷軸之間的映射關系。Haystack緩存主要用于解決對CDN提供商過于依賴的問題，提供最近增加的照片的緩存服務。

Haystack照片讀取請求大致流程為：用戶訪問一個頁面時，Web服務器請求Haystack目錄構造一個URL：http://＜CDN＞/＜Cache＞/＜Machine id＞/＜Logical volume,Photo＞，后續根據各個部分的信息依次訪問CDN、Haystack緩存和后端的Haystack存儲節點。Haystack目錄構造URL時可以省略＜CDN＞部分從而使得用戶直接請求Haystack緩存而不必經過CDN。CDN。Haystack緩存收到的請求包含兩個部分：用戶瀏覽器的請求及CDN的請求，Haystack緩存只緩存用戶瀏覽器發送的請求且要求請求的Haystack存儲節點是可寫的。一般來說，Haystack后端的存儲節點寫一段時間以后達到容量上限變為只讀，因此，可寫節點的照片為最近增加的照片，是熱點數據。本節暫不討論CDN，只討論Haystack后端存儲系統，包括Haystack目錄和Haystack緩存兩個部分。

1.寫流程

如圖4-7所示，Haystack的寫請求（照片上傳）處理流程為：Web服務器首先請求Haystack目錄獲取可寫的邏輯卷軸，接著生成照片唯一id并將數據寫入每一個對應的物理卷軸（備份數一般為3）。寫操作成功要求所有的物理卷軸都成功，如果中間出現故障，需要重試。

Haystack的一致性模型保證只要寫操作成功，邏輯卷軸對應的所有物理卷軸都存在一個有效的照片文件，但有效照片文件在不同物理卷軸中的偏移（offset）可能不同。

Haystack存儲節點只支持追加操作，如果需要更新一張照片，可以新增一張編號相同的照片到系統中，如果新增照片和原有的照片在不同的邏輯卷軸，Haystack目錄的元數據會更新為最新的邏輯卷軸；如果新增照片和原有的照片在相同的邏輯卷軸，Haystack存儲會以偏移更大的照片文件為準。

2.容錯處理

（1）Haystack存儲節點容錯

檢測到存儲節點故障時，所有物理卷軸對應的邏輯卷軸都被標記為只讀。存儲節點上的未完成的寫操作全部失敗，寫操作將重試；如果發生故障的存儲節點不可恢復，需要執行一個拷貝任務，從其他副本所在的存儲節點拷貝丟失的物理卷軸的數據；由于物理卷軸一般很大，比如100GB，所以拷貝的過程會很長，一般為小時級別。

2）Haystack目錄容錯

Haystack目錄采用主備數據庫（Replicated Database）做持久化存儲，由主備數據庫提供容錯機制。

3.Haystack目錄

Haystack目錄的功能如下：

1）提供邏輯卷軸到物理卷軸的映射，維護照片id到邏輯卷軸的映射；

2）提供負載均衡，為寫操作選擇邏輯卷軸，讀操作選擇物理卷軸；

3）屏蔽CDN服務，可以選擇某些圖片請求直接走Haystack緩存；

4）標記某些邏輯卷軸為只讀。

根據前面的計算結果可知，Facebook相冊系統每秒的寫操作大約為3500次，每秒的讀請求大約為100萬次。每個寫請求都需要通過Haystack緩存獲取可寫的卷軸，每個讀請求需要通過Haystack緩存構造讀取URL。這里需要注意，照片id到邏輯卷軸的映射的數據量太大，單機內存無法存放，筆者猜測內部使用了MySQL Sharding集群，另外，還增加了一個Memcache集群滿足查詢需求。

4.Haystack存儲

Haystack存儲保存物理卷軸，每個物理卷軸對應文件系統中的一個物理文件，每個物理文件的格式如圖4-8所示。

多個照片文件存放在一個物理卷軸中，每個照片文件是一個Needle，包含實際數據及邏輯照片文件的元數據。部分元數據需要裝載到內存中用于照片查找，包括Key（照片id，8字節），Alternate Key（照片規格，包括Thumbnail、Small、Medium及Large，4字節），照片在物理卷軸的偏移Offset（4字節），照片的大小Size（4字節），每張照片占用8+8+4=20字節的空間，假設每臺機器的可用磁盤為8TB，照片平均大小為80KB，單機存儲的照片數為8TB/80KB=100MB，占用內存100MB×20=2GB。

存儲節點宕機時，需要恢復內存中的邏輯照片查找表，掃描整個物理卷軸耗時太長，因此，對每個物理卷軸維護了一個索引文件（Index File），保存每個Needle查找相關的元數據。寫操作首先更新物理卷軸文件，然后異步更新索引文件。由于更新索引文件是異步的，所以可能出現索引文件和物理卷軸文件不一致的情況，不過由于對物理卷軸文件和索引文件的操作都是追加操作，只需要掃描物理卷軸文件最后寫入的幾個Needle，然后補全索引文件即可。這種技術在僅支持追加的文件系統很常見。

Haystack Store存儲節點采用延遲刪除的回收策略，刪除照片只是向卷軸中追加一個帶有刪除標記的Needle，定時執行Compaction任務回收已刪除空間。所謂Compaction操作，即將所有老數據文件中的數據掃描一遍，以保留最新一個照片的原則進行刪除，并生成新的數據文件。

討論

相比TFS,Haystack的一大特色就是磁盤空間回收。Blob文件在TFS中通過＜Block id,Block offset＞標識，因此，不能對TFS中的數據塊進行重整操作；而Haystack中的元信息只能定位到Blob文件所在的邏輯卷軸，Haystack存儲節點可以根據情況對物理卷軸進行Compaction操作以回收磁盤空間。

Facebook Haystack中每個邏輯卷軸的大小為100GB，這樣減少了元信息，但是增加了遷移的時間。假設限制內部網絡帶寬為20MB/s，那么遷移100GB的數據需要的時間為100GB/20MB/s=5000s，大約是一個半小時。而TFS設計的數據規模相比Haystack要小，因此，可以選擇64MB的塊大小，有利于負載均衡。

另外，Haystack使用RAID 6，并且底層文件系統使用性能更好的XFS，淘寶TFS不使用RAID機制，文件系統使用Ext3，由應用程序負責管理多個磁盤。Haystack使用了Akamai＆Limelight的CDN服務，而淘寶已經使用自建的CDN，當然，Facebook也在考慮自建CDN。