《Object Storage on CRAQ: High-throughput chain replication for read-mostly workloads》論文總結

CRAQ 論文總結

說明：本文爲論文 《Object Storage on CRAQ: High-throughput chain replication for read-mostly workloads》 的我的理解，不免有理解不到位之處，歡迎交流與指正 。

論文地址：CRAQ Paper

---

0. 簡介

Chain Replication with Apportioned Queries (CRAQ) 是一種對鏈式複製的改進，它經過在全部對象副本上分配負載，在保持強一致性的同時極大地提升了讀吞吐量。

本文主要對鏈式複製、CRAQ 原理以及 CRAQ 的一致性模型作出總結。

---

1. 對象存儲

在 基於對象 的存儲中，數據做爲整個單元呈現給應用程序。

對象存儲支持兩種基本原語：

• read 或 query 操做返回存儲在對象名稱下的數據塊
• write 或 update 操做更改單個對象的狀態

對象存儲更適合於平面名稱空間，例如鍵值數據庫，而不是層次目錄結構。對象存儲簡化了支持整個對象修改的過程，一般，它們只須要考慮對特定對象的修改順序，而不是整個存儲系統。爲每一個對象提供一致性保證成本要低得多。

---

2. 一致性模型

本文涉及到的兩種一致性模型爲：

• 強一致性：系統保證對一個對象的讀寫操做都以順序執行，而且對於一個對象的讀操做老是會觀察到最新被寫入的值。
• 最終一致性：在系統中，對一個對象的寫入還是按順序在全部節點上應用的，但對不一樣節點的最終一致性讀取可能會在一段時間內（即，在寫操做應用於全部節點以前）返回過期的數據。可是，一旦全部副本都接收到寫入操做，則讀操做將不會返回比最新提交的寫操做更早的版本。事實上，若是一個 client 維護與特定節點的會話，那麼它也會看到單調的讀一致性。

---

3. 鏈式複製

鏈式複製 (Chain Replication、CR) 是一種跨多個節點複製數據的方法：

• 節點造成一個長度爲 C 的鏈
• 鏈的頭部節點處理來自客戶端的全部寫操做
• 當一個節點接收到寫操做時，它將傳播到鏈中的每個節點
• 一旦寫入到達尾部節點，它就被應用於鏈中的全部副本，而且被認爲是提交的
• 當尾節點提交寫操做時，會向客戶端發送一個回覆
• 尾部節點處理全部讀操做，所以只有提交的值才能由讀操做返回

鏈式複製實現了 強一致性：因爲全部的讀操做都是在尾部進行的，而全部寫操做都在尾部提交，因此鏈尾能夠簡單地對全部操做應用一個總的順序。

鏈式複製的簡單拓撲使得寫操做比提供強一致性的其餘協議消耗更小。如在 Raft 中，leader 須要將每次寫操做都發送給全部的 follower ，可是 CRAQ 中，head 只須要將每一次寫操做發送一次；而且 Raft 中 leader 須要處理讀寫操做，而 CRAQ 中的 head 只須要處理寫操做。

鏈式複製的 故障恢復：

• 當頭節點出故障時：後續節點取代它成爲頭節點，沒有丟失的已提交寫操做
• 當尾節點出故障時：前一個節點取代它成爲尾節點，沒有丟失的寫操做
• 當中間節點故障時：從鏈中去掉，前一個節點須要從新發送最近的寫操做

侷限性：對一個對象的全部讀取必須都要轉到同一個節點，尾節點的負載很大。

---

4. CRAQ

4.1 CRAQ原理

CRAQ 是鏈式複製的一種改進，它容許鏈中的任何節點執行讀操做：

• CRAQ 每一個節點能夠存儲一個對象的多個版本，每一個版本都包含一個單調遞增的版本號和一個附加屬性（ 標識 clean 仍是 dirty ）

• 當節點接收到對象的新版本時（經過沿向下傳播的寫操做），該節點將此最新版本附加到該對象的列表中

  • 若是節點不是尾節點，則將版本標記爲 dirty ，並向後續節點傳遞寫操做
  • 若是節點是尾節點，則將版本標記爲 clean ，此時寫操做是 已提交 的。而後，尾節點在鏈中往回發送 ACK 來通知其餘節點提交

• 當對象版本的 ACK 到達節點時，該節點會將對象版本標記爲 clean 。而後，該節點能夠刪除該對象的全部先前版本

• 當節點收到對象的讀請求時：

  • 若是請求的對象的最新已知版本是乾淨的，則節點將返回此值
  • 不然，節點將與尾節點聯繫，詢問尾節點上該對象的最後提交版本號，而後，節點返回該對象的此版本

4.2 CRAQ性能提高

CRAQ 相對於 CR 的吞吐量改進發生在兩種不一樣狀況下：

• 讀密集型工做負載：讀操做能夠在全部節點上執行，所以吞吐量與鏈長度呈線性比例關係
• 寫密集型工做負載：大量寫操做的工做負載中，更容易讀取到 dirty 數據，所以對尾節點的查詢請求比較多。可是對尾節點查詢的工做負載遠低於全部讀請求都由尾節點來執行的工做負載，所以 CRAQ 吞吐量高於 CR。

4.3 CRAQ的一致性模型

對於讀操做， CRAQ 支持三種一致性模型：

• 強一致性：4.1 中描述的讀操做可使每次讀取都讀到最新寫入的數據，所以提供了強一致性
• 最終一致性：容許節點返回未提交的新數據，即容許 client 可從不一樣的節點讀到不一致的對象版本。可是對於一個 client 來講，因爲它與節點創建會話，因此它的讀操做是保證單調一致性的。
• 帶有最大不一致邊界的最終一致性：容許節點返回未提交的新數據，可是有不一致性的限制，這個限制能夠基於版本，也能夠基於時間。如容許返回一段時間內新寫入但未提交的數據。

4.4 split-brain 問題

若兩個相鄰節點之間的網絡鏈接斷開，後面的節點會想去成爲頭節點，這樣就會產生兩個頭節點。

CRAQ 自己並不會解決這樣的問題，因此須要外部的分佈式協調服務來解決這一問題，如使用 Zookeeper 。由 Zookeeper 來決定鏈的組成，決定哪一個節點是頭、尾，並監控哪一個節點出了故障。當發生網絡故障時，由 Zookeeper 來決定鏈的新組成，而不是基於各節點對於網絡狀況的自身感知。