Raft leader 選舉

通訊：兩種類型的RPC

• RequestVote RPCs candidates during elections.
• AppendEntries RPC leaders to replicate log entries and to provide a form of heartbeat.

leader 選舉

Raft使用一個heartbeat機制觸發leader選舉。當servers啓動，首先成爲followers。只要server收到來自leader或candidate的有效RPCs消息，就一直保持follower的狀態。
Leaders按期給全部的followers發送heartbeat，以維護它的統治。若是一個follower超過必定時間未通訊，則叫做election timeout，而後就假設如今沒有有效的leader，而後開始選舉流程選出新的leader。
在選舉以前，follower自增它當前的term號，轉化爲candidate狀態。而後投票給本身，並並行地給剩下的每個server發送 RequestVote RPCs。
Candidate保持candidate的狀態直到下面的一種狀況發生：
(a) 此candidate贏得選舉；
(b) 另外一個server已被選爲leader；
(c ) 一段時間過去後仍沒有server勝出。
下面的章節將分開討論這些狀況
(a) 在同一個term中，若是candidate得到大多數servers的選票，此candidate贏得這次選舉。在給定的term中，每個server最低投票給一個candidate，遵照先來先得的原則。大多數的規則保證最多一個candidate在特定的term中贏得選舉。一旦一個candidate贏得選舉，它就成爲leader。而後就開始發送heartbeat 信息到其餘全部的servers來創建它的權威並阻止新的選舉。
(b)在等待投票的過程當中，candidate可能會收到來自其餘自稱是leader的server的AppendEntries RPC。若是leader的term號至少與candidate的當前term號同樣大，則這個candidate就認爲這個leader是合理的，而後退回到follower的狀態。若是term號小於candidate的，則拒絕RPC並繼續保持candidate狀態。
(c ) 第三種結果是candidate既沒有贏也沒輸：若是許多followers同時成爲candidates，可能會發平生票。這種狀況下，每個candidate將timeout，經過遞增term開始一個新的選舉，產生新一輪的RequestVote RPCs。然而，沒有額外的措施，平票會無限重複下去。Raft使用隨機生成的選舉timeouts來保證平票發生的機會不多，並很快解決。爲了第一時間阻止平票，選舉timeouts在一個固定區間內隨機產生（e.g., 150-300ms)，從而保證在大多數狀況下，最多有一個server將time out;它贏得選舉並在其餘servers time out以前發送heartbeats。相同的機制也用來處理平票問題。