morning paper: strong consistent quorum read in

04-13

看了篇 paper，叫 Leader or Majority: Why have one when you can have both? Improving Read Scalability in Raft-like consensus protocols，比較短，大概是講如何在 raft 系統上，利用 non-leader 來做讀操作。話題很吸引人，因為一個 raft group 標準配置是 5 節點，如果另外 4 個節點都有辦法能用到那讀吞吐能提升很多，可以解決熱點問題。

這裡一個前提是有 MVCC 支持：每個 value 都需要帶一個 timestamp（版本號）。因為 paper 是在 cockroach 上做原型的，所以這點很自然。

quorum read

quorum read 就是把讀請求廣播給 non-leaders，拿到幾個版本的 value 之後，選擇版本最大的那個。

這種方法存在一種不一致的 case：雖然日誌已提交，但 non-leader 還未 apply 這條日誌（leader 收到過半響應，提交日誌，而 non-leader 尚未更新 committedIndex），導致 non-leader 與 leader 的讀結果不一致。這種情況發生頻繁。

由於不保證強一致性，這種方法比較沒實用意義。

Strong consistent quorum read

在 leader 的通知到來前，non-leader 無法知道最新的已提交日誌是哪個，這是主要矛盾。它擁有這條日誌，只是它的 committedIndex 未更新。

因為 non-leader 已擁有這條日誌，這時候可以根據尚未提交的結果，獲得 value 的最新版本，然後等待該版本提交。等待的方法就是不斷重試。

當然在 raft 里，一條未提交日誌可能最終會被 overwrite，導致重試的過程中，我們所等待的 timestamp 可能會被丟棄。這時候重試上述過程即可。

Evaluation

讀多寫少的場景下這種優化的優勢明顯，吞吐不必說，延遲也沒問題，畢竟：

讀多寫少，value 少更新，強一致問題少，讀延時影響小
leader 負載降低，自然降低寫延時

當然在這種優化下，還是可以將部分讀操作轉移給 leader，從而盡量減少讀延時。這就需要 tradeoff 了。

性能分析方面的之後再補吧，新人經驗少。