《大規模分散式儲存系統》第四章 分散式檔案系統
- GFS
系統特點：對大檔案友好，支援追加寫。
租約機制：Chunk之間通過租約機制選主，減少了Master的壓力。
追加流程
資料流是複製連，控制流與資料流分開。資料流是複製連的優點是，減少延時、節省頻寬，尤其是在跨交換機的情境下。
資料流與控制流分開的優點是，GFS專門設計給大檔案（捨棄小檔案），猜測可能是在異常情況下（例如，切主）減少頻寬（資料流記錄在日誌中，控制流決定是否寫入，如果切主可以重發控制流，不用發資料）。
多端併發，通過重試解決，Chunk上的資料保證資料的偏移量和長度一致，但不保證二進位制級別一致。
負載均衡：特別說明一下，GFS中限制了最近建立次數，防止新機器加入導致單點過熱問題。
快照：GFS支援檔案快照，這個實現比較複雜，機制比較經典。在元資料中需要記錄快照資訊，但是ChunkServer上的資料並不複製，而是寫時複製。
注：GFS的成功，說明單Master是可以支援幾k-1w甚至更大規模的叢集，只要設計合理。
- Taobao File System
業務特點：主要用於儲存淘寶網的圖片，寫少讀多，追加寫多、隨機寫少。
系統瓶頸
1. 資料量很大，元資料過大（100億張圖片，一張圖片100位元組，1TB源資料），解決方法是元資料分級中心節點存一部分，DataServer存一部分。
2. 讀多寫少的場景，大量的讀會導致IO次數放大，至少三次，第一是讀目錄到記憶體，第二是檔案的Inode載入到記憶體，第三是讀資料。解決方法是資料組織單位是Block，很多個圖片資料組成一個Block，一個Block對應一個物理檔案（類似Chunk）。
TFS架構
中心節點一主一備，強一致，通過外部服務監控切主。資料節點一主兩備，強一致模型，並未採用複製鏈的方式，更沒有將資料流與控制流分開。每個圖片有一個ID，與Block ID，組成唯一表示，作為元資料儲存在Meta表中。給每個圖片分一個ID，不用Block的偏移量和長度表示，主要還是考慮系統內部遷移、容災等情況下對業務的透明。DataServer會維護Block ID 與 圖片 ID的關係和索引。
追加流程
每次寫會請求Master詢問Block和主從關係，然後主強一致同步給兩個從。這樣做主要是業務場景為寫少。
注：TFS從介面上說不遵循POSIX介面，且不維護目錄樹，資料間不存在依賴關係，更像是物件系統或者Blob系統，與傳統的檔案系統區別較大。
- Facebook Haystack
業務特點
讀寫QPS較高，寫達到3.5K，讀甚至達到百萬級別。
系統架構
主要分為目錄、儲存、快取。目錄中的元資料包括照片ID多邏輯卷軸的對應關係，邏輯卷軸到物理卷軸的對應關係，一個物理卷軸100G。寫請求想目錄申請照片ID、邏輯卷軸以及對應的物理卷軸位置，客戶端寫三分保證強一致。
討論
100G的物理卷軸在資料遷移等操作是恢復時間較慢，20M頻寬預計1個半小時。
注：本文介紹的過於簡單，可以看論文了解更多。
- CDN
主要思想：靠近使用者的位置快取資料，分級快取，不命中回源。
接入層：4層結構 + 7層結構，保證效能 + 功能。
業務場景：Blob型別儲存寫少讀多，比較適合CDN，有事起熱點視訊更適合，寫一次讀可能達到上億次。
注意問題：資料失效，資料被刪除之後如何使CDN及時失效？
- 總結
GFS作為檔案系統的鼻祖，論文更是被廣泛研究，本文著重介紹了GFS，其他部分主要是針對不同的設計方案進行了一下對比，並沒有過多詳細的介紹。