Raft 協議

今天看  redis 哨兵部分的時候看見 哨兵選leader  採用的是 Raft協議，因而就瞭解了一下Raft協議；

1、簡介

a、Raft 協議是借鑑了 Paxos協議，可是思路又與Paxos不同

b、主要思想：多數成員贊成/同意就能成爲master/leader

與Paxos協議的區別

a、Paxos 協議對leader選舉沒有明確限制，可是必定要保證數據一致性，數據同步很複雜；

b、Raft 協議能夠有多個leader存在，可是同時被承認的leader只會有一個，同步數據就比Paxos容易；

 

2、原理

Raft協議大體有如下幾種狀況

a、數據廣播策略（主正常）

a、選leader（發現主異常）

b、新leader數據同步（選主後）

補充：

一、數據都是線性的，即：有自增加的標識符

二、每一個節點leader/follow的數據都分爲committed和uncommitted兩種數據，committed的數據不能被修改，而uncommitted的數據（老是在committed數據後）能夠被刪除和修改；

三、每一次選舉產生leader後會有一個記錄號Term，自增加

 

3、數據廣播策略

a、當前leader收到客戶端數據，會將數據記錄下來，可是是uncommitted狀態

b、當前leader就會廣播最新的數據，並帶上本身的Term

c、follow節點就會比對當前leader的Term，若是比本身記錄的當前leader小就丟棄該數據（保證同一時間只有一個leader能同步數據）

d、當超過半數的follow節點認爲數據有效/可提交，則leader提交數據，記錄下最新的commit-index，並將commit-index廣播給follow節點

e、follow節點提交數據並更新各自的commit-index

 

4、leader選舉

a、全部的follow節點都能成爲candidate（有資格成爲leader）

b、當一個candidate發現leader網絡有問題時，candidate就會發起選主（選本身）投票

c、各個follow就會比對與candidate數據的長度（不是commit-index），只有超過半數follow認爲candidate日誌長度要大於等於本身的日誌長度，candidate才能成爲leader

問題：可能各個follow都會發起選leader投票，致使多輪投票，系統很長時間不能選leader成功

解決：

a、每一輪投票時間長度設置成隨機，保證儘量在同一時間只會有一個candidate在發起投票；

b、各個follow的投票時間也時隨機的，保證同一時間，同一個follow儘量只參加一輪投票；

 

5、新leader同步數據

a、新leader會去詢問全部follow的數據最大長度（不是commit-index）

b、將最長的數據同步過來

c、帶上本身當選leader的Term並廣播數據同步，參考第三段

 

結束語：

哨兵的選主實現

a、每一個哨兵每秒去輪詢各個節點的狀態，當發現redis-master掛掉後，發現redis-mster掛掉的哨兵就會認爲該redis-master主觀下線；

b、將每10s一次的info同步信息策略提高爲1s一次的

c、詢問其餘哨兵當前redis-master是否已經下線

d、超過半數的哨兵認爲當前redis-master已經下線，那麼就認爲該redis-master客觀下線

e、客觀下線後，該哨兵就會發起選主（選哨兵leader）投票，這經過epoch來表示Term，同一個epoch中，一個哨兵只能投一次票

f、哨兵選主（投票超過max(配置票數，哨兵節點數/2+1)）成功後，就會進行故障轉移，選新的redis-master