互聯網應用經常需要存儲用戶上傳的文檔、圖片、視頻等，比如Facebook相冊、淘寶圖片、Dropbox文檔等。文檔、圖片、視頻一般稱為Blob數據，存儲Blob數據的文件系統也相應地稱為Blob存儲系統。每個Blob數據一般都比較大，而且多個Blob之間沒有關聯。Blob文件系統的特點是數據寫入后基本都是只讀，很少出現更新操作。這兩節分別以Taobao File System和Facebook Haystack為例說明Blob文件系統的架構。

2007年以前淘寶的圖片存儲系統使用了昂貴的NetApp存儲設備，由于淘寶數據量大且增長很快，出于性能和成本的考慮，淘寶自主研發了Blob存儲系統Tabao File System（TFS）。目前，TFS中存儲的圖片規模已經達到百億級別。

TFS架構設計時需要考慮如下兩個問題：

Metadata信息存儲。由于圖片數量巨大，單機存放不了所有的元數據信息，假設每個圖片文件的元數據占用100字節，100億圖片的元數據占用的空間為10G×0.1KB=1TB，單臺機器無法提供元數據服務。

減少圖片讀取的IO次數。在普通的Linux文件系統中，讀取一個文件包括三次磁盤IO：首先讀取目錄元數據到內存，其次把文件的inode節點裝載到內存，最后讀取實際的文件內容。由于小文件個數太多，無法將所有目錄及文件的inode信息緩存到內存，因此磁盤IO次數很難達到每個圖片讀取只需要一次磁盤IO的理想狀態。

因此，TFS設計時采用的思路是：多個邏輯圖片文件共享一個物理文件。

系統架構

TFS架構上借鑒了GFS，但與GFS又有很大的不同。首先，TFS內部不維護文件目錄樹，每個小文件使用一個64位的編號表示；其次，TFS是一個讀多寫少的應用，相比GFS,TFS的寫流程可以做得更加簡單有效。

如圖4-4所示，一個TFS集群由兩個NameServer節點（一主一備）和多個DataServer節點組成，NameServer通過心跳對DataSrver的狀態進行監測。NameServer相當于GFS中的Master,DataServer相當于GFS中的ChunkServer。NameServer區分為主NameServer和備NameServer，只有主NameServer提供服務，當主NameServer出現故障時，能夠被心跳守護進程檢測到，并將服務切換到備NameServer。每個DataServer上會運行多個dsp進程，一個dsp對應一個掛載點，這個掛載點一般對應一個獨立磁盤，從而管理多塊磁盤。

在TFS中，將大量的小文件（實際數據文件）合并成一個大文件，這個大文件稱為塊（Block），每個Block擁有在集群內唯一的編號（塊ID），通過＜塊ID，塊內偏移＞可以唯一確定一個文件。TFS中Block的實際數據都存儲在DataServer中，大小一般為64MB，默認存儲三份，相當于GFS中的chunk。應用客戶端是TFS提供給應用程序的訪問接口，應用客戶端不緩存文件數據，只緩存NameServer的元數據。

1.追加流程

TFS中的追加流程相比GFS要簡單有效很多。GFS中為了減少對Master的壓力，引入了租約機制，從而將修改權限下放到主ChunkServer，很多追加操作都不需要Master參與。然而，TFS是寫少讀多的應用，即使每次寫操作都需要經過NameNode也不會出現問題，大大簡化了系統的設計。另外，TFS中也不需要支持類似GFS的多客戶端并發追加操作，同一時刻每個Block只能有一個寫操作，多個客戶端的寫操作會被串行化。

如圖4-5所示，客戶端首先向NameServer發起寫請求，NameServer需要根據DataServer上的可寫塊、容量和負載加權平均來選擇一個可寫的Block，并且在該Block所在的多個DataServer中選擇一個作為寫入的主副本（Primary），其他的作為備副本（Secondary）。接著，客戶端向主副本寫入數據，主副本將數據同步到多個備副本。如果所有的副本都修改成功，主副本會首先通知NameServer更新Block的版本號，成功以后才會返回客戶端操作結果。如果中間發生任何錯誤，客戶端都可以從第一步開始重試。相比GFS,TFS的寫流程不夠優化，第一，每個寫請求都需要多次訪問NameServer；第二，數據推送也沒有采用流水線方式減小延遲。淘寶的系統是需求驅動的，用最簡單的方式解決用戶面臨的問題。

每個寫操作返回后，會返回客戶端兩個信息，小文件在TFS中的Block編號（Block id）以及Block偏移（Block offset）。應用系統會將這些信息保存到數據庫中，圖片讀取的時候首先根據Block編號從NameServer查找Block所在的DataServer，然后根據Block偏移讀取圖片數據。TFS的一致性模型保證所有返回給客戶端的＜Blockid,Block offset＞標識的圖片數據在TFS中的所有副本都是有效的。

2.NameServer

NameServer主要功能是：Block管理，包括創建、刪除、復制、重新均衡；Data-Server管理，包括心跳、DataServer加入及退出；以及管理Block與所在DataServer之間的映射關系。與GFS Master相比，TFS NameServer最大的不同就是不需要保存文件目錄樹信息，也不需要維護文件與Block之間的映射關系。

NameServer與DataServer之間保持心跳，如果NameServer發現某臺DataServer發生故障，需要執行Block復制操作；如果新DataServer加入，NameServer會觸發Block負載均衡操作。和GFS類似，TFS的負載均衡需要考慮很多因素，如機架分布、磁盤利用率、DataServer讀寫負載等。另外，新DataServer加入集群時也需要限制同時遷入的Block數量防止被壓垮。

NameServer采用了HA結構，一主一備，主NameServer上的操作會重放至備NameServer。如果主NameServer出現問題，可以實時切換到備NameServer。

討論

圖片應用中有幾個問題，第一個問題是圖片去重，第二個問題是圖片更新與刪除。

由于用戶可能上傳大量相同的圖片，因此，圖片上傳到TFS前，需要去重。一般在外部維護一套文件級別的去重系統（Dedup），采用MD5或者SHA1等Hash算法為圖片文件計算指紋（FingerPrint）。圖片寫入TFS之前首先到去重系統中查找是否存在指紋，如果已經存在，基本可以認為是重復圖片；圖片寫入TFS以后也需要將圖片的指紋以及在TFS中的位置信息保存到去重系統中。去重是一個鍵值存儲系統，淘寶內部使用5.2節中的Tair來進行圖片去重。

圖片的更新操作是在TFS中寫入新圖片，并在應用系統的數據庫中保存新圖片的位置，圖片的刪除操作僅僅在應用系統中將圖片刪除。圖片在TFS中的位置是通過＜Block id,Block offset＞標識的，且Block偏移是在Block文件中的物理偏移，因此，每個Block中只要還有一個有效的圖片文件就無法回收，也無法對Block文件進行重整。如果系統的更新和刪除比較頻繁，需要考慮磁盤空間的回收，這點會在Facebook Haystack系統中具體說明。