[zookeeper]-raft協議

參考:https://raft.github.io/

工做原理

一、一個節點能夠在3個狀態中的1個 follower狀態 candidate 狀態 或者leader
二、咱們全部的節點都是從跟隨者狀態開始的
三、若是追隨者沒有聽到領導者的消息，他們能夠成爲候選人
四、候選人而後請求其餘節點的投票
五、節點將回復他們的投票
六、若是從多數節點得到選票，候選人就成爲領導者。
七、這個過程被稱爲領導者選舉
八、如今系統的全部變化都經過領導
九、每一個更改都添加爲節點日誌中的條目
十、此日誌條目當前未提交，所以它不會更新節點的值
十一、爲了提交條目，節點首先將它複製到跟隨者節點
十二、這時領導等待，直到大多數節點已經寫入條目
1三、該條目如今在領導者節點上提交而且節點狀態爲「5」
1四、領導者而後通知追隨者該條目已經落實
1五、該集羣如今已經就係統狀態達成共識
1六、這個過程叫日誌複製

raft 領導人選舉

一、在raft裏有兩個超時設置來控制選舉 二、首先是選舉超時 2.1 選舉超時是一個追隨者在成爲候選人以前等待的時間。 2.2 這選舉超時是在150ms和300ms之間的隨機數 3.在選舉超時以後，追隨者成爲候選人並開始新的選舉任期 四、選舉本身 五、併發送請求投票消息給其餘節點。 六、若是接收節點還沒有在此期間投票，那麼它會爲候選人投票 七、而且該節點重置其選舉超時 八、一旦候選人得到多數選票，它就成爲領導者。 九、領導者開始向追隨者發送附加條目消息。 10.這些消息以心跳超時指定的間隔發送。
十一、追隨者而後迴應每一個追加條目消息 十二、這個選舉任期將持續到跟隨者中止接受心跳併成爲候選人

讓咱們中止領導人，並觀看從新選舉

一、Node B如今是第2任期的領導人 二、要求多數選票保證每一個任期只能選舉一名領導人 三、若是兩個節點同時成爲候選，則可能發生分裂投票。 四、讓咱們來看看一個分割投票的例子… 4.1 兩個節點都開始選舉相同的期限.. 4.2 而且每一個都在另外一個節點以前到達單個跟隨器節點 4.3 如今每一個候選人有2票，而且不能再收到這個任期 4.4 節點將等待新的選舉並再次嘗試

日誌複製

1.一旦咱們選出了一個領導者，咱們就須要把咱們的系統的全部變化複製到全部節點上
二、這是經過使用用於心跳的相同附加條目消息來完成的
三、首先客戶端發送變化給leader
四、這一變化被加到領導的日誌上。
五、而後在下一次心跳中將變化發送給追隨者。
六、一旦大多數追隨者認可，就提交一個條目。
七、並將響應發送給客戶端
八、如今讓咱們發送一個命令，經過「2」來增長值

raft和zab關係

由於raft比zab出來晚點,可能raft 裏面的有些東西會借鑑zab協議.其實兩個協議差不到哪裏去,本質上都是維護一個replicated log. 相同點(不全,沒有實現過zab): 都使用timeout來從新選擇leader. 採用quorum來肯定整個系統的一致性(也就是對某一個值的承認), 這個quorum通常實現是集羣中半數以上的服務器, zookeeper裏還提供了帶權重的quorum實現.都由leader來發起寫操做.都採用心跳檢測存活性. leader election都採用先到先得的投票方式.

不一樣點(不全,沒有實現過zab): zab用的是epoch和count的組合來惟一表示一個值, 而raft用的是term和index.zab的follower在投票給一個leader以前必須和leader的日誌達成一致, 而raft的follower則簡單地說是誰的term高就投票給誰. raft協議的心跳是從leader到follower, 而zab協議則相反.
raft協議數據只有單向地從leader到follower(成爲leader的條件之一就是擁有最新的log),

而zab協議在discovery階段, 一個prospective leader須要將本身的log更新爲quorum裏面最新的log,而後纔好在synchronization階段將quorum裏的其餘機器的log都同步到一致.