一致性算法Raft分為哪些模塊

這篇文章主要介紹“一致性算法Raft分為哪些模塊”，在日常操作中，相信很多人在一致性算法Raft分為哪些模塊問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”一致性算法Raft分為哪些模塊”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

一：一致性算法Raft

Raft 算法：Raft 是一種為了管理復制日志的一致性算法，Raft提供了和Paxos算法相同的功能和性能，但是它的算法結構和Paxos不同。

Raft將一致性算法分解成了3模塊：

1. 領導人選舉

2. 日志復制

3. 安全性

二個階段：首先是選舉過程，然后在選舉出來的領導人帶領下進行正常操作，比如日志復制等。

1.1 領導人選舉

在Raft中，任何時候一個服務器都可以扮演下面的角色之一：

領導者(leader)：處理客戶端交互，日志復制等動作，一般一次只有一個領導者
候選者(candidate)：候選者就是在選舉過程中提名自己的實體，一旦選舉成功，則成為領導者
跟隨者(follower)：類似選民，完全被動的角色，這樣的服務器等待被通知投票

Raft使用心跳機制來觸發選舉。當server啟動時，初始狀態都是follower。每一個server都有一個定時器，超時時間為election timeout（一般為150-300ms），如果某server沒有超時的情況下收到來自領導者或者候選者的任何消息，定時器重啟，如果超時，它就開始一次選舉。

1. 初始狀態下集群中的所有節點都處于 follower 狀態。
   

2. 某一時刻，其中的一個 follower 由于沒有收到 leader 的 heartbeat 率先發生 election timeout 進而發起選舉。
   

3. 只要集群中超過半數的節點接受投票，candidate 節點將成為即切換 leader 狀態。
   

4. 成為 leader 節點之后，leader 將定時向 follower 節點同步日志并發送 heartbeat。
   

1.2 可能遇到的節點異常

1）leader 不可用

1. 一般情況下，leader 節點定時發送 heartbeat 到 follower 節點，由于某些異常導致 leader 不再發送 heartbeat ，或 follower 無法收到 heartbeat 。

2. 當某一 follower 發生 election timeout（超時機制，該時間內未收到心跳包） 時，其狀態變更為 candidate，并向其他 follower 發起投票。

3. 當超過半數的 follower 接受投票后，這一節點將成為新的 leader，leader 的步進數加 1 并開始向 follower 同步日志。

當一段時間之后，如果之前的 leader 再次加入集群后：

4. 兩個 leader 比較彼此的步進數，步進數低的 leader 將切換自己的狀態為 follower。

5. 較早前 leader 中不一致的日志將被清除，并與現有 leader 中的日志保持一致。

2）follower 節點不可用

follower 節點不可用的情況相對容易解決。因為集群中的日志內容始終是從 leader 節點同步的，只要這一節點再次加入集群時重新從 leader 節點處復制日志即可。

3）多個 candidate

多個 candidate 比較容易出現在集群節點啟動初期尚未選出 leader 的“混沌”時期。

1. 初始狀態下集群中的所有節點都處于 follower 狀態，此時兩個節點同時成為 candidate 發起選舉。

2. 兩個 candidate 都只得到了少部分 follower 的接受投票。

3. candidate 繼續向其他的 follower 詢問，由于一些 follower 已經投過票了，所以均返回拒絕接受。

4. candidate 也可能向另一個 candidate 詢問投票，在步進數相同的情況下，candidate 將拒絕接受另一個 candidate 的請求。

5. 由于第一次未選出 leader，candidate 將隨機選擇一個等待間隔（150ms ~ 300ms）再次發起投票，如果得到集群中半數以上的 follower 的接受，這一 candidate 將成為 leader。

6. 稍后另一個 candidate 也將再次發起投票，由于集群中已經選出 leader，candidate 將收到拒絕接受的投票。

7. 在被多數節點拒絕之后，并已知集群中已存在 leader 后，這一 candidate 節點將終止投票請求、切換為follower，從 leader 節點同步日志。

1.3 日志復制（保證數據一致性）

日志復制的過程

Leader選出后，就開始接收客戶端的請求。Leader把請求作為日志條目（Log entries）加入到它的日志中， 然后并行的向其他服務器發起 AppendEntries RPC復制日志條目。當這條日志被復制到大多數服務器上，Leader 將這條日志應用到它的狀態機并向客戶端返回執行結果。

下圖表示了當一個客戶端發送一個請求給領導者，隨后領導者復制給跟隨者的過程如下：

• 客戶端的每一個請求都包含被復制狀態機執行的指令。

• leader把這個指令作為一條新的日志條目添加到日志中，然后并行發起 RPC 給其他的服務器，讓他們復制這條信息。

• 跟隨者響應ACK,如果 follower 宕機或者運行緩慢或者丟包，leader會不斷的重試，直到所有的 follower 最終都復制了所有的日志條目。

• 通知所有的Follower提交日志，同時領導人提交這條日志到自己的狀態機中，并返回給客戶端。

可以看到，直到第四步驟，整個事務才會達成。中間任何一個步驟發生故障，都不會影響日志一致性。

到此，關于“一致性算法Raft分為哪些模塊”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！