一致性協(xié)議raft詳解（四）：raft在工程實踐中的優(yōu)化

• • 前言
  • 性能優(yōu)化
  • client對raft集群的讀寫
  • 參考鏈接

前言

有關(guān)一致性協(xié)議的資料網(wǎng)上有很多，當(dāng)然錯誤也有很多。筆者在學(xué)習(xí)的過程中走了不少彎路。現(xiàn)在回過頭來看，最好的學(xué)習(xí)資料就是Leslie Lamport和Diego Ongaro的數(shù)篇論文、Ongaro在youtube上發(fā)的三個視頻講解，以及何登成的ppt。

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

性能優(yōu)化

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

性能優(yōu)化主要有以下幾點：

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

Batch 和 Pipeline

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

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

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

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

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

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

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

針對慢節(jié)點做優(yōu)化（GFS、mapreduce等存儲系統(tǒng)中也有類似優(yōu)化，不做詳述了）

raft功能完善

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

client對raft集群的讀寫

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

寫

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

讀

• 最簡單可以通過Quorum方式讀
• raft因為有l(wèi)eader，可以從leader上去讀，但是為了防止網(wǎng)絡(luò)分區(qū)導(dǎo)致的假leader對raft一致性的破壞，可以用以下方式優(yōu)化：
  • 對讀請求也執(zhí)行raft協(xié)議，會有額外的overhead
  • leader通過之前講到的某種優(yōu)化方法，確認自己是真正的leader之后，才提供讀寫請求服務(wù)。

客戶端要有冪等性保證

參考鏈接

The Raft Consensus Algorithm raft 官方網(wǎng)站

RAFT介紹 百度braft寫的raft介紹

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。