《大規模分佈式存儲系統》讀書摘記（持續更新）

3 分佈式系統

3.5 容錯

故障檢測：

• 心跳協議；
• 當機器發生故障時，須要將上面的服務遷移到其餘服務器上，爲了保證強一致性，須要確保故障機器再也不提供服務；
• 主要問題：正常機器和故障機器之間須要對「故障機器是否應該被認爲發生故障而中止服務」達成一致。異步網絡中多態機器沒法達成一致。
• 租約：帶有超時時間的一種受權。考慮一個提早量。P51

故障恢復：

• 分佈式存儲系統分爲：單層結構和雙層結構。通常都爲單層，每一個數據分片維護多個副本；Bigtable爲雙層，存儲和服務分開，服務層只有一個副本。
• 單層結構系統維護多個副本，貯備副本之間經過操做日誌同步。
• 兩層結構系統將全部數據持久化寫入底層的共享分佈式文件系統，每一個數據分片同一時刻只有一個提供服務的節點。
• 故障檢測和故障恢復過程當中，不能提供寫服務和強一致性讀服務。故障檢測事件較長，通常爲幾秒到十幾秒，故障恢復時間較短，兩層結構故障恢復只是將數據索引加載到內存中，而不是數據。
• 爲了實現高可用性，總控節點也須要一個備機。

 

3.6 可擴展性

總控節點：

• 通常分佈式系統中總控節點只需維護數據分片的位置信息，並執行調度，分佈式文件系統中還須要維護文件系統目錄樹，因此內存容量可能會優先成爲瓶頸。
• 若是總控節點成爲瓶頸，能夠採用兩級結構。在總控機與工做機之間增長一層，雖然看似增長了一次網絡請求，可是客戶端老是可以緩存總控機上的元數據，所以並不會帶來額外的開銷。

數據庫擴容：

• 假設數據庫中有3張表格，首先根據業務將三張表格垂直拆分到不一樣的DB中，再將每張表經過哈希的方式水平拆分到不一樣的存儲節點。每一個拆分後的DB經過主從複製維護多個副本，且容許分佈到多個數據中心。
• 一般採用雙倍擴容，將每一個分片拆分爲兩個分片。

異構系統：

• 同構系統：將存儲節點分爲若干組，每組內的節點服務相同的數據，一個節點爲主節點，其他爲從節點。這樣的系統的問題在於增長副本時要遷移的數據量很是大，時間長，在遷移的過程當中頗有可能存儲節點再次發生故障。因此這樣的節點很難作到自動化。
• 異構系統：每一個分片的副本能夠分佈到集羣中的任何一個存儲節點。發生故障時，原有的服務有整個集羣的存儲節點來恢復。因爲整個集羣參與恢復數據，故恢復時間短，集羣越大，效果越明顯。

 

3.7 分佈式協議

兩階段提交協議（2PC）：

• 保證跨多個節點操做的原子性，實現分佈式事務
• 兩類節點：協調者（一個），事物參與者（多個）
• 兩個階段：①請求提交。協調者通知參與者準備提交或者取消事務，而後進入表決過程。在表決階段，參與者將告知協調者本身的決策（贊成或取消）。②當且僅當全部參與者贊成提交事務，協調者才通知全部的參與者提交事務，不然通知取消事務。
• 兩階段提交協議是阻塞協議，執行過程當中須要鎖住其餘更新，且不能容錯，大部分分佈式系統都敬而遠之，放棄對分佈式事務的支持。

Paxos協議：

• 解決多個節點之間一致性問題（經過操做日誌同步數據）
• 主節點故障，多個備節點提議本身成爲主節點，Paxos協議保證全部節點最終達成一致。
• ........

Paxos與2PC：

• Paxos用於保證一個數據分片的多個副本之間的數據一致性（尤爲分佈在不一樣的數據中心時）
• 2PC用於保證多個數據分片的操做的原子性（多態服務器上的操做要麼所有成功要麼所有失敗）
• Paxos的兩種用法：①實現全局的鎖服務或者命名和配置服務（Google Chubby以及Apache Zookeeper）②將數據複製到多個數據中心（Google Megastore以及Google Spanner）
• 2PC與Paxos結合使用：2PC保證多個數據分片上的操做的原子性，Paxos保證一個數據分片的多個副本之間的一致性。Paxos解決2PC協議中協調者宕機的問題，當協調者出現宕機時，Paxos選舉出新的協調者繼續提供服務

跨機房部署：

• 集羣總體部署（較常見），每一個機房一個總控節點
• 單個集羣跨機房部署，總共一個總控節點
• Paxos選主副本，總控節點和工做節點不須要保持租約

 

4 分佈式文件系統

4.1 Google文件系統

系統架構：

• 三種角色：GFS Master（主控服務器）、GFS ChunkServer（CS，數據塊服務器）、GFS客戶端
• 客戶端（GFS提供給應用程序的訪問接口）首先訪問主控節點，獲取CS信息，而後訪問CS獲取數據
• 客戶端只緩存元數據，不緩存文件（由GFS應用特色決定）

關鍵問題：

• 租約機制：
• Master將寫chunk經過租約受權給CS，該CS稱爲主CS，其餘副本所在CS爲備CS。
• 若是其中一個chunk備副本下線後又上線，在此過程當中主副本有更新，此時Master會刪除過時的chunk（經過版本號解決）。
• 一致性模型：
• GFS主要設計爲追加而不是改寫，主要是由於追加的一致性模型相對簡單（追加失敗只是讀到過時數據，而不是錯誤數據）
• 多客戶端併發追加時可能出現數據被打斷，致使數據不連續的問題，即某些數據中夾雜這其餘客戶端的數據（追求性能致使，由應用層處理這些問題）
• 追加流程
• 追加流程請看書
• 兩個特點：流水線（減小延時）和分離數據流、控制流（優化數據傳輸）
• 容錯機制
• Master容錯：操做日誌、檢查點、實時熱備
• Master上存儲的三種數據：命名空間、文件到chunk的映射、chunk副本的位置
• Master先操做日誌再修改內存
• Master持久化前兩種數據，能夠選擇不持久化第三種數據，由於chunk副本位置信息在CS上也有保存
• chunk的全部副本寫入成功纔算成功
• CS會對存儲的數據維持校驗和（chunk以64M爲單位，chunk又以64KB爲單位劃分爲Block，每一個Block對應一個32位校驗和）
• 讀取一個chunk時會比較校驗和

Master設計：

• Master內存佔用：
• 前兩種數據持久化存儲，最後一種不持久化，前面說過了
• 不會成爲系統的瓶頸
• 負載均衡：
• chunk的全部副本不會放在同一個機架
• 影響chunk副本建立位置的因素：①新副本所在CS的磁盤利用率低於平均水平；②限制每一個CS「最近」建立的數量；③每一個chunk的全部副本不能在同一個機架。
• 以上第二點保證一臺剛上線的CS不會由於磁盤利用率低致使大量chunk遷移上來而將它壓垮的狀況
• 副本數小於必定數量以後會複製，有一個優先級
• Master按期掃描副本分佈狀況，發現磁盤使用量或機器負載不均衡，將執行從新負載均衡操做
• 限制從新複製和從新負載均衡任務的拷貝速度，以避免影響正常讀寫

• 垃圾回收
• 延遲刪除
• Master按期檢查，若是刪除文件超過一段時間，就把文件從內存元數據中刪除，在心跳協議中Master通知CS哪些chunk被刪除
• 快照：
• 使用寫實複製機制生成快照
• 「快照」只增長chunk一個引用計數，修改的時候才複製成新chunk，再對其作修改
• 步驟：①經過租約機制回收對文件的每一個chunk寫權限，中止對文件的寫服務；②Master拷貝文件名等元數據生成一個新的快照文件；③對執行快照的文件的全部chunk增長引用計數

ChunkServer設計：

• 刪除chunk時只須要將chunk移動到每一個磁盤的回收站，新建chunk時能夠重用
• 磁盤和IO密集型應用，須要將磁盤和網絡操做異步化

 

4.2 Taobao File System（Blob存儲系統）

• 文檔、圖片、視頻通常成爲Blob數據，存儲Blob數據的系統成爲Blob系統，Blob文件系統的特色是寫入後基本都是隻讀，不多出現更新操做。
• 兩個問題：①Metadata信息量過大，沒法存儲在單臺機器上；②減小圖片讀取的IO次數
• 設計思路：多個邏輯圖片文件共享一個物理文件

系統架構：

• 借鑑GFS，可是有很大不一樣。
• 不維護文件目錄樹，每一個小文件用64位編號表示；因爲讀多寫少，能夠將寫流程作的更加簡單有效
• 一個集羣兩個NameServer（一主一備）、多個DataServer，NS經過心跳對DS監測。
• 每一個DS上有多個dsp進程，每一個dsp對應一個掛載點，一個掛載點對一個獨立磁盤
• 大量小文件合併成一個大文件（64M的Block），並有惟一ID，默認存儲三份
• 應用客戶端不緩存文件數據，只緩存NS元數據
• 追加流程：
• TFS讀多寫少，及時每次寫操做都通過NS也不會出現問題
• 不支持多客戶端寫，同一時刻每一個Block只能有一個寫操做，多個客戶端的寫操做會被串行化
• TFS寫流程不夠優化：①每一個寫請求都須要屢次訪問NS；②數據推送沒有采用流水線方式減小延遲

討論：

• 經過Tair進行對圖片去重。採用hash算法爲圖片文件計算指紋，圖片寫入以前在Tair中查找是否存在指紋，寫入之後須要將指紋以及在TFS中的位置信息保存到去重系統（Tair）中
• 圖片在TFS中的位置經過<Block id, File id>來標識

 

4.3 Fackbook Haystack

系統架構：

• 設計思路：多個邏輯文件共享一個物理文件（和TFS相似）
• 三部分：目錄（邏輯卷着和物理卷軸的對應關係、照片id到邏輯卷着之間的映射關係）、存儲（以一個很大的物理卷軸爲單位，多個存儲節點上的物理卷軸組成一個邏輯卷軸）、緩存（解決對CDN過於依賴的問題）
• Haystack緩存只緩存用戶瀏覽器發送的請求且要求請求的Haystack存儲節點是可寫的
• 寫流程：
• 請求Haystack目錄獲取邏輯卷軸 -> 生成照片惟一id將數據寫入每個對應的物理卷軸（每個物理卷軸都要成功）
• 只支持追加操做，更新照片時增長一張編號相同的照片到系統中，若邏輯卷軸和原來的不一樣，則在目錄中修改爲最新的邏輯卷着，若邏輯卷軸相同，以偏移大的照片文件爲準
• 容錯處理：
• 存儲節點出錯時，全部物理卷軸對應的邏輯卷軸標記爲只讀；未完成寫操做所有失敗；若故障不可恢復，須要進行拷貝（小時級別）
• 目錄有貯備數據庫作持久化儲存，由主備數據庫提供容錯機制
• Haystack目錄功能：
• ①提供邏輯卷軸到物理卷軸的映射，維護照片id到邏輯卷軸的映射；
• ②提供負載均衡；
• ③屏蔽CDN服務；
• ④標記某些邏輯卷軸爲只讀

 

5 分佈式鍵值系統

5.1 Amazon Dynamo

• 存儲原始數據，不解析數據的具體內容
• Dynamo設計時面臨的問題及最終的解決方案：
• 數據分佈                   ：   改進的一致性哈希（虛擬節點）
• 複製協議                   ：   複製寫協議
• 數據衝突處理            ：   向量時鐘
• 臨時故障處理            ：   數據回傳機制
• 永久故障後的恢復     ：   Merkle哈希樹
• 成員資格及錯誤檢測  ：   基於Gossip的成員資格和錯誤檢測協議

數據分佈：

• 採用改進的一致性哈希算法將數據分佈到多個存儲節點中
• Dynamo中每一個節點維護整個集羣的信息，客戶端也緩存整個集羣的信息
• 爲保證每一個節點緩存最新的成員信息，全部節點週期性經過Gossip協議從其餘節點任意選擇一個與之通訊的節點，鏈接成功後交換集羣信息
• Gossip協議的執行過程請看書（P87）
• 種子節點

一致性與複製：

• 思路：假設數據存儲N份，DHT（一致性哈希表）定位到的數據所屬節點爲K，則數據存儲在節點K、K+一、....、K+N-1上。若是第K+i（0<=i<=N-1）臺機器宕機，則日後找一臺機器K+N臨時替代；若是第K+i臺機器重啓，則數據回傳；若永久失效，機器K+N須要進行數據同步操做（Merkle樹）
• NWR：N表示複製的備份數，R表示成功讀操做的最少節點數，W表示成功寫操做的最少節點數
• 當W+R>N時，就能保證當存在不超過一臺機器故障的時候，至少可以讀到一份有效數據
• 向量時鐘用[nodes，counter]對錶示，nodes表示節點，counter表示初始爲0的計數器，更新一次加1（P89）
• Dynamo只保證最終一致性，若是多個節點之間的更新順序不一致，客戶端可能讀取不到指望的結果

容錯：

• 數據回傳（臨時故障）
• Merkle樹同步（永久故障）：Merkle樹非葉子節點對應多個文件（子節點值組合後的哈希值），葉子節點對應單個文件（文件內容的哈希值）
• 讀取修復（NWR）

負載均衡：

• 隨機分配。效果不錯，但可控性比較差
• 數據範圍等分+隨機分配

讀寫流程：

• 寫數據：
• 根據一致性哈希計算出存儲節點，選擇一個副本做爲本次寫的協調者
• 併發的往全部副本發送寫請求，每一個副本將接收到的數據寫入本地
• 副本寫入成功後回覆協調者
• 若寫入失敗，協調者會將它加入重試列表不斷重試
• 全部協調者寫入成功後，協調者回復客戶端寫入成功
• 讀數據：
• 根據一致性哈希選擇存儲節點，選擇一個副本做爲本次讀的協調者
• 協調者根據併發策略選擇R個副本，併發發送讀請求
• 當全部副本都讀取成功時，協調者回復客戶端
• 兩種狀況：數據一致和數據不一致