MongoDB副本集主節點的選舉過程

MongoDB的復制集具有自動容忍部分節點宕機的功能，在復制集出現問題時時，會觸發選舉相關的過程，完成主從節點自動切換。每個復制集成員都會在后臺運行與復制集所有節點的心跳線程，在兩種情況下會觸發狀態檢測過程：

1. 復制集成員心跳檢測結果發生變化，比如某個節點掛了或者新增節點；
2. 超過4s沒有執行狀態檢測過程。在狀態檢測過程大致包含以下步驟：

（1）檢測自身是否處于選舉過程，如果是，退出本次過程。
（2）維護一個主節點的備用列表，列表中所有節點都可能被選舉為主節點，每個節點都會檢測自身以及全局條件是否滿足：
a. 是否看見復制集中有Majority在線。
b. 自身priority大于0。
c. 自身不為arbiter。
d. 自身opTime不能落后于最新節點10s以上。
e. 自身存儲的集群程序按信息為最新。
如果所有條件滿足，則將自身添加到主節點備用列表中，否則，將自身從列表中移除。

檢測以下條件，若都滿足，將主節點降為從節點（如果要降級的主節點是自身，直接調用降級方法，如果不為自身，調用replSetStepDown命令將復制集主節點降級為從節點：
    a. 集群中主節點存在。
    b. "主節點的備用列表”中存在比當前的主節點priority更高的節點。
    c. "主節點的備用列表”中priority最高的節點，其opTime要比其他所有節點最新的opTime落后10s以內。
    d. 檢測自身是否為主，若為主，且自身無法看見復制集的Majority在線，將自身降級為從。
    e. 如果看不見集群中有主節點存在，檢測自身是否在”主節點的備用列表”，若不在，打印log并退出此流程。
    f. 若自身在”主節點的備用列表”中，開始判斷自身可否向復制集中發送選舉自身為主節點的通知，判斷過程包含：
         1> 自身是否可以看見復制集中的Majority在線。
         2>自身是否在”主節點的備用列表”。

若條件滿足，則設置”自身已經在選舉過程中”標識位為true，并進入”選舉自身為主節點”方法。
方法中會驗證自身是否滿足以下條件：
a. 此線程拿到了線程鎖。
b. 此節點沒有被配置slaveDelay選項或者配置的slaveDelay為0。
c. 此節點沒有被配置為arbiter。
若滿足，則調用環境檢測，若以下條件被觸發，則不發送"選舉我為主節點”投票：
1> 當前時間小于steppedDown的結束凍結時間（為執行steppedDown時的時間+凍結設定時間，內部調用為60s）。
2> 自己的opTime不是所有節點最新的。
3> 若有節點opTime比自己新，直接退出此流程。
如果其他最新的節點最多與自己一樣新，每有一個這樣的節點，隨機sleep一段時間，之后繼續判斷。
a. 自己上線5分鐘內且復制集中不是所有節點在線。
b. 如無其他問題，嘗試獲取自己進行投票時的票數，在此過程中，會判斷自己在30s內是否進行過投票，如進行過，直接退出整個過程。
經過以上種種復雜的檢測，終于可以向復制集發送”選舉我為主節點”的投票。
發送之后，會接收來自所有節點的投票，若得票數小于等于一半，不將自己變為主節點，若超過一半，設置自己為主節點。
投票結束后，設置”自身已經在選舉過程中”標識位為false。
可以看到，上面的判斷邏輯有一些是重復判斷，不過不影響最終結果，可能與判斷邏輯較為復雜有關系，在每個決定之前都要驗證所有條件是否滿足，防止有條件被漏掉。
在復制集中的節點收到其他節點發送的”選舉我為主節點”投票信息時，會有以下的判斷：
a. 若自身存儲的復制集配置版本過低，不投票。
b. 若發起請求的節點存儲的復制集配置版本過低，投反對票。
c. 如果自身所在的復制集沒有發起投票的節點，投反對票。
d. 復制集中存在主節點，投反對票。
可參與選舉的節點中有priority高于請求為主的節點存在時，投反對票。
如果所有條件通過，獲取自身的投票數（同樣會判斷自身在30s內是否參加過投票，若參加過，不再投票），投出票數。
需要說一下的是，一個反對會將最終票數減10000，即在絕大多數情況下，只要有節點反對，請求的節點就不能成為主節點。
選舉過程很復雜，實際使用中總結為兩點：
一般情況下需要5s左右進行選主。
如果新選舉出的主節點立馬掛掉，至少需要30s時間重新選主。