1 小紅維護上司人權威

在上篇文章

中，小紅成功當選了上司者。

小藍和小黃雖然在之前的流程中承認了小紅的上司者地位，但互相之間的通信是不可靠的，是以小黃和小藍都有逾時機制，如果超過一定時間沒收到小紅的消息，會重新發起選舉流程。

針對這種情況，小紅會定時向小藍和小黃發送MsgHeartbeat資訊，用來阻止小藍和小黃啟動選舉流程。

小紅和小藍收到資訊後，會更新自身逾時設定歸0，然後傳回MsgHeartbeatResp消息

2 特殊場景-小紅遇到比自身term大的MsgApp怎麼辦

case1 小紅（id=1，term=1，state=follower，leader = 2）收到了來自小藍（id=3）message（type=MsgApp，term=2）

case2 小紅（id=1，term=1，state=candidate）收到了來自小藍（id=3）message（type=MsgApp，term=2）

case3 小紅（id=1，term=1，state=leader）收到了來自小藍（id=3）message（type=MsgApp，term=2）

小紅發現自己的term 1 小于 message中的term 2，會轉變自己身份為follower身份，同時更新自己的term為2，leader為3（小藍），最後回複MegAppResp消息

case1 小紅（id=1，term=1）目前是follower或者candidate角色，目前随機的選舉逾時時間（randomizedElectionTimeout）為19秒，當過了19秒，小紅依然沒收到任何消息，這時候的處理流程如下：

有這樣一種情形，當小紅成功變為candidate後，會向小夥伴們（小黃、小藍、小綠、小紫。。。）發送投票請求MsgApp，有的人會同意，同的人會拒絕，遇到這種情形，小紅該如何處理

case1 目前叢集裡隻有小紅一人，id=1，term =1

case2 目前叢集有3人，小紅為candidate，小黃和小藍投了贊成票

假設小紅先收到小黃（id=2）的投票，這時小紅儲存的投票狀态為（votes_[1] = true，votes_[2] = true），已經滿足了半數+1（即2）的要求，狀态直接成為leader
後續小紅再收到小藍（id=3）的投票，這時小紅已經是leader了，是以不再響應小藍的請求

case3 目前叢集有3人，小紅為candidate，小黃投了贊成票，小藍無響應

case4 目前叢集有5人，小紅為candidate，小黃和小藍投了贊成票，其他人或者拒絕或者沒有投票

假設小紅（id=1）先收到小黃（id=2）的贊成票，投票狀态為（votes_[1] = true，votes_[2] = true）（即2人），5個人的半數+1為3人，還不滿足條件，繼續維持現在的狀态
然後小紅收到了小藍（id=3）的贊成票，狀态為（votes_[1] = true，votes_[2] = true，votes_[3] = true），已經有3人，滿足半數條件，小紅成為leader
無論其他人投任何票，都不會再影響小紅的狀态。

case 5 目前叢集有3人，小黃和小藍都投了拒絕票

小紅先收到小黃的拒絕請求，狀态為（votes_[1] = true，votes_[2] = false），已投票人中拒絕的人有1個，叢集半數+1為2,1 < 2，是以維持小紅的candidate狀态
小紅繼續收到小藍的拒絕請求，狀态為（votes_[1] = true，votes_[2] = false，votes_[3] = false），已投票中拒絕的人變為2個，等于叢集的半數+1（2），小紅狀态直接變為follower

case5 目前叢集有5人，其中小紅是candidate，除了小紅外，（1）有一個人投贊成，其他人沒有投票。（2）有兩人投反對票，其他人沒有投票。（3）沒有人投票