一致性協議raft詳解（四）：raft在工程實踐中的優化

• • 前言
  • 性能優化
  • client對raft集群的讀寫
  • 參考鏈接

前言

有關一致性協議的資料網上有很多，當然錯誤也有很多。筆者在學習的過程中走了不少彎路。現在回過頭來看，最好的學習資料就是Leslie Lamport和Diego Ongaro的數篇論文、Ongaro在youtube上發的三個視頻講解，以及何登成的ppt。

本系列文章是只是筆者在學習一致性協議過程中的摘抄和總結，有疏漏之處敬請諒解，歡迎討論。

性能優化

• TiKV 源碼解析系列 - Raft 的優化
• 條分縷析 Raft 算法(續)：日志壓縮和性能優化

性能優化主要有以下幾點：

Writing to the leader’s disk in parallel Leader 可以在向 Follower 并行復制日志的同時寫入自己的磁盤，如果多數派 Follower 已經寫入磁盤，Leader 甚至可以在該記錄寫入自己的磁盤之前就提交，這仍然是安全的。

Batch 和 Pipeline

• Batch：Leader 可以一次收集多個客戶端 requests，然后一批發送給 Follower。當然，我們也需要有一個最大發送 size 來限制每次最多可以發送多少數據，LogCabin 使用 1M 大小。
• Pipeline：如果只是用 batch，Leader 還是需要等待 Follower 返回才能繼續后面的流程，我們這里還可以使用 Pipeline 來進行加速。Leader 會維護一個 nextIndex 的變量來表示下一個給 Follower 發送的 log 位置，通常情況下，只要 Leader 跟 Follower 建立起了連接，我們都會認為網絡是穩定互通的。所以當 Leader 給 Follower 發送了一批 log 之后，它可以直接更新 nextIndex，并且立刻發送后面的 log，不需要等待 Follower 的返回。如果網絡出現了錯誤，或者 Follower 返回一些錯誤，Leader 就重新調整 nextIndex，然后重新發送 log。
  • 最初的線程架構阻礙了 pipeline，因為它只能支持每個 Follower 一個 RPC。這里 Leader 必須多線程地與一個 Follower 建立多個連接。
  • 如果 Leader 與一個 Follower 共用一個連接使用 pipeline 的話, 那么效果會是怎樣的呢?其實這樣和 Batch 沒有多大區別，tcp 層面已經是串行的了，tcp 有滑動窗口來做 batch，同時單條連接保證了消息很少會亂序。
  • 那么，如果使用多線程連接的話可能存在什么問題？即使因為在多個連接中不能保證有序，但是大部分情況還是先發送的先到達；即使后發送的先到達了，由于有 AppendEntries RPC 一致性檢查的存在，后發送的自然會失敗，失敗后重試即可。

pre-vote：**網絡分區會導致某個節點的數據與集群最新數據差距拉大，但是 term 因為不斷嘗試選主而變得很大。網絡恢復之后，Leader 向其進行日志復制時，就會導致 Leader 因為 term 較小而下臺。**這種情況可以引入 pre-vote rpc 來避免。Follower 在轉變為 Candidate 之前，先與集群節點通信，獲得集群 Leader 是否存活的信息，如果當前集群有 Leader 存活，Follower 就不會轉變為 Candidate，也不會增加term。參考上面的段落。并且只有在獲得半數以上投票之后，才會增加自己的term，然后發request vote rpc

MultiRaft：raft節點過多之后，各節點間心跳開銷很大。CockroachDB將raft分為raft組，心跳也分為了組間心跳和組內心跳。各個組之間每次只交換一個心跳，而不像之前那樣所有的節點都會提供心跳。

在上一任leader還存在的時候，不會進行選主

Leader Lease：上一任Leader的Lease過期后，隨機等待一段時間再發起Leader選舉，保證新舊Leader的Lease不重疊。

Leader Stickiness：Leader Lease未過期的Follower拒絕新的Leader選pm舉請求。

百度在上面leader stickiness的基礎上，實現了靜默模式：braft 提供了靜默模式：通常復制組不需要頻繁的切換 Leader，我們可以將主動 Leader Election 的功能關閉，這樣就不需要維護 Leader Lease 的心跳了。復制組依靠業務 Master 進行被動觸發 Leader Election，這個可以只在 Leader 節點宕機時觸發，整體的心跳數就從復制實例數降為節點數。

針對慢節點做優化（GFS、mapreduce等存儲系統中也有類似優化，不做詳述了）

raft功能完善

Raft 系統的整體性能在很大程度上取決于如何安排 batch 和 pipeline。如果在高負載的情況下，一個 batch 中積累的請求數量不夠，整體處理效率就會很低，導致低吞吐量和高延遲。另一方面，如果在一個 batch 中積累了太多的請求，延遲將不必要地變高，因為早期的請求要等待后來的請求到達。

client對raft集群的讀寫

經過之前內容的闡述，我們已經明白了why what how raft，以及各種優化。現在讓我們再回到一個最基本的問題上：一個客戶端如何對raft集群進行讀取寫？

寫

• 由于raft協議的特性，寫請求必須由leader發起，由leader負責向整個raft集群寫入，寫成功后返回，
• 只要對該請求執行raft協議成功，那么必然能提供各種保證

讀

• 最簡單可以通過Quorum方式讀
• raft因為有leader，可以從leader上去讀，但是為了防止網絡分區導致的假leader對raft一致性的破壞，可以用以下方式優化：
  • 對讀請求也執行raft協議，會有額外的overhead
  • leader通過之前講到的某種優化方法，確認自己是真正的leader之后，才提供讀寫請求服務。

客戶端要有冪等性保證

參考鏈接

The Raft Consensus Algorithm raft 官方網站

RAFT介紹 百度braft寫的raft介紹

理論基礎 · Raft phd 論文中的pipeline 優化那么使用多條連接的話可能存在什么問題?

總結

以上是生活随笔為你收集整理的一致性协议raft详解（四）：raft在工程实践中的优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。