Raft leader 選舉
通訊：兩種型別的RPC
- RequestVote RPCs candidates during elections.
- AppendEntries RPCleaders 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。相同的機制也用來處理平票問題。