一致性協議raft詳解（一）：raft介紹

• • 前言
  • 概述
  • • raft獨特的特性
    • • raft集群的特點
    • raft中commit何意？
  • raft leader election
  • log replication
  • 網絡分區
  • • Symmetric network partitioning
    • Asymmetric network partitioning
    • StepDown
  • raft沖突解決方法
  • 參考鏈接

前言

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

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

概述

一致性協議的目的是實現CAP，最好在CA之間有很好的平衡，既保證高可用，又保證一致性

所以這類算法大概涉及兩個方面

leader的選舉

多副本狀態機的每個副本上都保存有完全相同的操作日志，保證所有狀態機副本按照相同的順序執行相同的操作

raft只保證了不同節點上的log可以最終達成一致，至于應用log的狀態機的一致性不是raft的任務，應自行實現

raft獨特的特性

• 強領導者：和其他一致性算法相比，**Raft 使用一種更強的領導能力形式。**比如，日志條目只從領導者發送給其他的服務器。這種方式簡化了對復制日志的管理并且使得 Raft 算法更加易于理解。
• 領導選舉：Raft 算法使用一個隨機計時器來選舉領導者。這種方式只是在任何一致性算法都必須實現的心跳機制上增加了一點機制。在解決沖突的時候會更加簡單快捷。
• 成員關系調整：Raft 使用一種共同一致的方法來處理集群成員變換的問題，在這種方法下，處于調整過程中的兩種不同的配置集群中大多數機器會有重疊，這就使得集群在成員變換的時候依然可以繼續工作。

Raft 算法保證所有已提交的日志條目都是持久化的并且最終會被所有可用的狀態機執行。

raft日志保證：

• 如果在不同的日志中的兩個條目擁有相同的索引和任期號，那么他們存儲了相同的指令。因為同一個任期只有一個leader，leader最多在一個任期里在指定的一個日志索引位置創建一條日志條目
• 如果在不同的日志中的兩個條目擁有相同的索引和任期號，那么他們之前的所有日志條目也全部相同。因為日志在raft節點中必須是順序添加的。leader保存著每個follower當前的日志進展，并持續給follower推送
• 但是某條log到底能不能被commit，還是要看他有沒有被大多數節點接受（Figure 8） （并且整個集群具備冪等性）

特性解釋

選舉安全特性	對于一個給定的任期號，最多只會有一個領導人被選舉出來（5.2 節）
領導人只附加原則	領導人絕對不會刪除或者覆蓋自己的日志，只會增加（5.3 節）
日志匹配原則	如果兩個日志在相同的索引位置的日志條目的任期號相同，那么我們就認為這個日志從頭到這個索引位置之間全部完全相同（5.3 節）
領導人完全特性	如果某個日志條目在某個任期號中已經被提交，那么這個條目必然出現在更大任期號的所有領導人中（5.4 節）
狀態機安全特性	如果一個領導人已經將給定的索引值位置的日志條目應用到狀態機中，那么其他任何的服務器在這個索引位置不會應用一個不同的日志（5.4.3 節）

raft集群的特點

摘自何登成老師的ppt

• 系統存在一個Leader角色（Proposer），接受Clients發過來的所有讀寫請求
• Leader負責與所有的Followers（Acceptors）通信，將提案/Value/變更復制到所有Followers，同時收集多數派Followers的應答
• 少數派宕機，不會影響系統整體的可用性
• Leader日常維護與所有Followers的心跳
• Leader宕機，會觸發系統自動重新選主，選主期間系統對外不可服務

raft中commit何意？

The leader decides when it is safe to apply a log entry to the state machines; such an entry is called committed.

raft作者說只要leader把當前log寫入自己的RSM中，就算是commit了（該日志已經被系統中大部分節點接受），并且提供raft一致性協議的以下兩點保證：

已經commit提交的日志不會再修改（可靠性），這里指不會更改，其意為Quorum不會更改，單個節點上的數據還是會被leader更改。

所有節點上的數據一致（希望達到線性一致性）

Our goal for Raft is to implement linearizable semantics (each operation appears to execute instantaneously, exactly once, at some point between its invocation and its response).

raft leader election

leader選舉原則：最大提交原則: During elections, choose candidate with log most likely to contain all committed entries

• Follower在收到Leader或者Candidate的RPC請求的情況下一直保持Follower狀態。而當一段時間內（election timeout）沒有收到請求則認為沒有Leader節點而出發選舉流程。
• 選舉開始之后，自己作為candidate，先投自己一票，向其他candidate發選舉請求，如果自己收到選舉請求并且自己沒有選舉過，就把票投出去
• 某臺機器收到投票過半，則成為主
• 選舉windows的時長是隨機決定的（150ms-300ms） electionTimout，這種方式只是在任何一致性算法都必須實現的心跳機制上增加了一點機制。在解決沖突的時候會更加簡單快捷。
• 如果follower在election timeout超時了，會成為candidate；如果heartbeat timeout超時了，也會成為candidate
• 其實不太會出現那種大家一起變成candidate，導致投票一直失敗那種情況，因為electionTimout是一個隨機的，包括服務剛起來的時候也會等一個隨機的時間
• 安全性：
  • 擁有最新的已提交的log entry的Follower才有資格成為Leader（相當于是term（任期）和log entry都要最大）
    • 這個保證是在RequestVote RPC中做的，Candidate在發送RequestVote RPC時，要帶上自己的最后一條日志的term和log index，其他節點收到消息時，如果發現自己的日志比請求中攜帶的更新，則拒絕投票。日志比較的原則是，如果本地的最后一條log entry的term更大，則term大的更新，如果term一樣大，則log index更大的更新。
      • 這點隱含了一個事實：如果一個candidate能當選主，那么它一定包含了最新的日志，并且最新這條日志被半數以上節點承認。
        • 抽屜原理，選舉出來的Leader是多數中數據最新的，一定包含已經在多數節點上commit的數據
  • Leader只能推進commit index來提交當前term的已經復制到大多數服務器上的日志，舊term日志的提交要等到提交當前term的日志來間接提交（log index 小于 commit index的日志被間接提交）。
    • 還有一種實現方式是，保證只讓最大commit index的人做leader，就算是因為網絡分區導致一些stale節點的term值很大，leader也會先收到這個leader選舉rpc之后追齊term（StepDown），然后再次成為leader，這也就是為什么braft的文檔中說原始的RAFT論文中對非對稱的網絡劃分處理不好
• 在等待投票的時候，候選人可能會從其他的服務器接收到聲明它是leader的附加日志項 RPC。如果這個leader的任期號（包含在此次的 RPC中）不小于候選人當前的任期號，那么候選人會承認leader合法并回到跟隨者狀態。 如果此次 RPC 中的任期號比自己小，那么候選人就會拒絕這次的 RPC 并且繼續保持候選人狀態。

log replication

client寫給leader的log，會被leader同步給follower，

一旦半數以上的follower被寫成功了，leader就可以回client成功了（并且可以寫入自己的log了（如果除自己外一半寫成功了，就需要寫入自己才能回client，如果除自己外一半以上寫成功了，自己不寫入就可以先回client）），這時follower的log還是uncommit狀態（是否有uncommit這個狀態要看系統實現是怎樣的）

返回client之后，leader再通知follower，這條log就被commit了。(這步也可以沒有，還是看系統實現是怎樣的，比如6.824就沒要求你做prepare/commit)

某些Followers可能沒有成功的復制日志，Leader會無限的重試 AppendEntries RPC直到所有的Followers最終存儲了所有的日志條目。

不一致的時候：

Leader通過強制Followers復制它的日志來處理日志的不一致，Followers上的不一致的日志會被Leader的日志覆蓋。

Leader為了使Followers的日志同自己的一致，Leader需要找到Followers同它的日志一致的地方，然后覆蓋Followers在該位置之后的條目。

Leader會從后往前試，每次AppendEntries失敗后嘗試前一個日志條目，直到成功找到每個Follower的日志一致位點，然后向后逐條覆蓋Followers在該位置之后的條目。

兩種情況：

leader發送給follower之后還沒有得到回復就下線了

leader發送很多個logindex給follower，但是并不是每個follower都收到了一樣的index，他們可能有大有小（這時候leader是要保序的？）

網絡分區

主要摘自baidu braft文章

Symmetric network partitioning

原始的RAFT論文中對于對稱網絡劃分的處理是，一個節點再次上線之后，Leader接收到高于currentTerm的RequestVote請求就進行StepDown。這樣即使這個節點已經通過RemovePeer刪除了，依然會打斷當前的Lease，導致復制組不可用。對于這種case可以做些特殊的處理：Leader不接收RequestVote請求，具體情況如下：

對于屬于PeerSet中的節點，Leader會在重試的AppendEntries中因為遇到更高的term而StepDown

對于不屬于PeerSet中的節點，Leader永遠忽略

這樣，屬于PeerSet中的節點最終能夠加入，不屬于PeerSet的節點不會加入也不會破壞。如果網絡劃分是因為節點故障導致的，那么穩定的多數復制組不會收到更高term的AppendEntries應答，Leader不會StepDown，這樣節點可以安靜的加入集群。

Asymmetric network partitioning

原始的RAFT論文中對非對稱的網絡劃分處理不好，比如S1、S2、S3分別位于三個IDC，其中S1和S2之間網絡不通，其他之間可以聯通。這樣一旦S1或者是S2搶到了Leader，另外一方在超時之后就會觸發選主，例如S1為Leader，S2不斷超時觸發選主，S3提升Term打斷當前Lease，從而拒絕Leader的更新。這個時候可以增加一個trick的檢查，每個Follower維護一個時間戳記錄收到Leader上數據更新的時間，只有超過ElectionTImeout之后才允許接受Vote請求。這個類似Zookeeper中只有Candidate才能發起和接受投票，就可以保證S1和S3能夠一直維持穩定的quorum集合，S2不能選主成功。

StepDown

RAFT原始協議中Leader收到任何term高于currentTerm的請求都會進行StepDown，在實際開發中應該在以下幾個時刻進行StepDown：

Leader接收到AppendEntries的失敗應答，Term比currentTerm大

Leader在ElectionTimeout內沒有寫多數成功，通過logic clock檢查實現（1個ElectionTimeout內會有10個HeartBeat）

Leader在進行RemovePeer的LogEntry被Commit的時候，不在節點列表中，進行StepDown，通常還會進行Shutdown

raft沖突解決方法

在 Raft 算法中，leader處理不一致是通過強制follower直接復制自己的日志來解決的。這意味著在follower中的沖突的日志條目會被leader的日志覆蓋。

• 要使得跟隨者的日志進入和自己一致的狀態，leader必須找到最后兩者達成一致的地方（最簡單的方法就是領導者一個個的減少index去試，看哪個能append成功），然后刪除從那個點之后的所有日志條目，發送自己的日志給跟隨者。

參考鏈接

解讀Raft（一 算法基礎）

Raft在etcd中的實現（三）選舉流程

Raft一致性算法中集群成員變更 節點由少變多的話要維護中間狀態，否則會出現由于只有一部分節點更新了節點數目，導致的雙主

Raft算法詳解 寫得很好

Paxos、Raft分布式一致性算法應用場景 簡單介紹了CAP，以及CAP為什么不能滿足三者，寫的很好，一致性協議入門必讀

ZooKeeper和CAP理論及一致性原則zookeeper是CP

OceanBase的一致性協議為什么選擇 paxos而不是raft?

分布式一致性算法-Paxos、Raft、ZAB、Gossip只寫了選舉，太簡單了

Raft協議處理各種failover情況這個寫的很好

The Raft Consensus Algorithmraft 官方網站

RAFT介紹百度braft寫的raft介紹，寫的挺好的，真的要看看

分布式系統中的冪等性

raft可能出現丟數據么？日志落后的人不會被選為主

MIT 6.824 Raft 設計文檔

分布式一致性算法-Raft學習筆記

如何理解拜占庭將軍問題？

為 Raft 引入 leader lease 機制解決集群腦裂時的 stale read 問題stale read一般出現在有網絡分區的時候

etcd raft如何實現Linearizable Read

強一致性、順序一致性、弱一致性和共識

Students’ Guide to Raft助教寫的指南

分布式系統理論之Quorum機制swift用到了，防止腦裂的思想和一般的zk選主不一致

NameNode 高可用整體架構概述HDFS的namenode使用zk選取主節點

深入理解Hadoop HDFS【一篇就夠】整個HDFS集群由Namenode和Datanode構成master-worker（主從）模式。Namenode負責構建命名空間，管理文件的元數據等，而Datanode負責實際存儲數據，負責讀寫工作。

微信分布式數據存儲協議對比——Paxos和Quorum 寫的挺好的

分布式一致性最強算法之Paxos透析 paxos和Quorum

Parameter Server for Distributed Machine Learning

2020 MIT 6.824 分布式系統課程 Kylin創始人

Raft一致性算法論文的中文翻譯

When does a term begin and end in Raft?人工的定義一個term的任期是沒有必要的，因為leader election會造成不可服務。在設計系統的時候要盡量避免。但是raft作者在figure5中說的話仍是正確的，分布式系統何時會發生term變更時不確定的，有可能因為網絡波動、網絡分區、節點宕機而導致term變更

raft協議里面，leader只能commit自己任期內的日志這條規則，仔細推理的話似乎是有空間的？

Raft 作者親自出的 Raft 試題，你能做對幾道？

Immutable 詳解及 React 中實踐 immutable 數據結構

精讀 Immutable 結構共享

logcabin

Immutable collections for JavaScript immtable-js官方文檔

分布式Server中使用braft來構建高可用系統包含raft中各種rpc操作，可以看看

LVM文件的備份和恢復lvm可以實現快照

Log-structured file systems: There’s one in every SSD

Log-structured File System

Linearizability versus Serializability

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

Raft 算法原理及其在 CMQ 中的應用（上）raft論文翻譯的挺詳細的

一文看盡 Raft 一致性協議的關鍵點log recovery/no-op/membership變更/為什么Current Term、VotedFor需要持久化

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的一致性协议raft详解（一）：raft整体介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

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