來源：小技術君

介紹

Raft是當前廣泛使用的共識演算法。流行的系統，如Kafka、Cockroach DB、MongoDB、Neo4j、Splunk等，都使用Raft來實現共識。系統要麼是最終一致性的，要麼是強一致性的。線性一致性是一致性模型中最強大的，但實現它可能很耗時。鍵值資料庫出現在市場上，以避免SQL資料庫的複雜性並提供橫向擴充套件性。這些資料庫主要提供兩種操作：get(key)和put(key, value)。在我對Raft相關論文的探索中，我找到了一篇有趣的文章，標題為‘Rethink the Linearizability Constraints of Raft for Distributed Key-Value Stores’。本文詳細介紹了在類似鍵值資料庫中減少讀寫線性操作延遲以提高吞吐量的技術。本文提供了對這篇論文的簡要概述。

Raft如何處理寫請求？

Raft處理寫請求涉及三個關鍵操作：追加（Append）、提交（Commit）和應用（Apply），因此引入了一系列用於讀寫請求處理的索引，以確保線性一致性。這些索引包括日誌索引、提交索引和應用索引。

圖片來源：Paper 9458806

追加

當客戶端向領導者傳送寫請求時，請求中的日誌將被分配一個唯一遞增的索引號。領導者將日誌附加到本地日誌儲存，並向跟隨者傳送用於複製的附加條目請求。領導者收到來自大多數跟隨者的附加條目請求的響應後，將日誌設定為已提交，即新寫入的資料在系統中是安全的。

提交

當領導者收到附加條目請求的大多數跟隨者的響應時，日誌被設定為已提交，即新寫入的資料在系統中是安全的。

應用

領導者開始將已提交的日誌應用到其本地狀態機，並並行通知跟隨者執行相同的操作。每個節點在應用操作成功後將更新其應用索引。只有在領導者將日誌應用到狀態機之後，領導者才能向客戶端返回響應。

寫請求序列

Raft如何處理讀請求？

為了實現線性一致性，所有讀請求都由領導者自身處理。Raft還為此引入了讀索引。當領導者收到讀請求時，請求的讀索引設定為當前提交索引。只有當領導者的應用索引不小於讀索引時，領導者才能執行讀請求並將結果返回給客戶端。在這種情況下，我們可以確保客戶端不會獲取到陳舊的資料。

讀請求序列

對這些操作的評估

文章討論了所有這些操作的時間消耗評估，如複製、提交和應用。根據評估，應用操作是最耗時的。對於帶有高速網路的系統，網路開銷較低。日誌的結構簡單，日誌附加通常是一個具有較高速度的順序I/O操作。因此，更新複雜的狀態機最可能成為效能瓶頸。

下圖顯示了值大小從1KB到1MB時，應用操作和所有其他操作的時間消耗百分比。它顯示應用實際上是慢的，佔寫請求總時間的近40%。

如何改進這個？

與其他型別的資料庫相比，鍵值儲存是一個簡單的資料庫。寫操作只是將鍵和值插入或更新到資料庫，而讀操作只是為給定的鍵讀取相應的值。文章證明，去除請求處理中的應用階段可能會減少延遲。應用操作可以非同步執行。讀和寫操作不需要等待應用完成。為此，文章引入了兩種新方法：

a) 提交返回（用於寫操作）

b) 立即讀（用於讀操作）

提交返回

這個想法是一旦請求中的日誌被提交，直接向客戶端返回成功響應，而不必等待將日誌應用到狀態機。因此，這個方法被稱為提交返回。提交返回不會破壞KV儲存的正確性和線性一致性。

提交返回

立即讀

在Raft中，讀操作在查詢狀態機之前等待應用索引追上讀索引。當實施提交返回時，應用索引和讀索引之間的差距會比傳統Raft方法中的差距更大。因此，提交返回可以提升寫處理但可能降低讀處理。然而，如果

我們能夠消除由於應用索引和讀索引之間的差距而引起的等待時間，讀效能將得到顯著改善。

由於鍵值對的讀操作簡單，我們可以直接根據位於讀索引和應用索引之間的日誌資料副本執行讀請求，而不必查詢狀態機。如果日誌中存在鍵的值，則立即返回，否則查詢狀態機並返回結果。透過這種方式，讀效能將大大提高。

例子：立即讀

採用這種方法，平均寫入延遲將減少36.4% ∼ 39.9%，平均讀取延遲將減少5.8% ∼ 16.2%，與Raft相比。有關詳細資訊，請參閱實際論文，文章中提供了論文連結。

參考資料

•Rethink the Linearizability Constraints of Raft for Distributed Key-Value Stores•In Search of an Understandable Consensus Algorithm