下篇 來詳細的講解 崩潰恢復模式 的原理

一、什麼情況下zab協議會進入崩潰恢復模式？

   1、當伺服器啟動時

    2、當leader 伺服器出現網路中斷，崩潰或者重啟的情況

    3、當叢集中已經不存在過半的伺服器與Leader伺服器保持正常通訊。

二、zab協議進入崩潰恢復模式會做什麼？

    1、當leader出現問題，zab協議進入崩潰恢復模式，並且選舉出新的leader。當新的leader選舉出來以後，如果叢集中已經有過半機器完成了leader伺服器的狀態同（資料同步），退出崩潰恢復，進入訊息廣播模式。

  2、當新的機器加入到叢集中的時候，如果已經存在leader伺服器，那麼新加入的伺服器就會自覺進入崩潰恢復模式，找到

三、特殊情況下需要解決的兩個問題：

    1、已經被處理的事務請求（proposal）不能丟（commit的）

     2、沒被處理的事務請求（proposal）不能再次出現

什麼時候會出現事務請求被丟失呢？

  當 leader 收到合法數量 follower 的 ACKs 後，就向各個 follower 廣播 COMMIT 命令，同時也會在本地執行 COMMIT 並向連線的客戶端返回「成功」。但是如果在各個 follower 在收到 COMMIT 命令前 leader 就掛了，導致剩下的伺服器並沒有執行都這條訊息。

如何解決 已經被處理的事務請求（proposal）不能丟（commit的）呢？

 1、選舉擁有 proposal 最大值（即 zxid 最大） 的節點作為新的 leader：由於所有提案被 COMMIT 之前必須有合法數量的 follower ACK，即必須有合法數量的伺服器的事務日誌上有該提案的 proposal，因此，zxid最大也就是資料最新的節點儲存了所有被 COMMIT 訊息的 proposal 狀態。

 2、新的 leader 將自己事務日誌中 proposal 但未 COMMIT 的訊息處理。
 3、新的 leader 與 follower 建立先進先出的佇列， 先將自身有而 follower 沒有的 proposal 傳送給 follower，再將這些 proposal 的 COMMIT 命令傳送給 follower，以保證所有的 follower 都儲存了所有的 proposal、所有的 follower 都處理了所有的訊息。

問題二出現的場景是：

    當 leader 接收到訊息請求生成 proposal 後就掛了，其他 follower 並沒有收到此 proposal，因此經過恢復模式重新選了 leader 後，這條訊息是被跳過的。 此時，之前掛了的 leader 重新啟動並註冊成了 follower，他保留了被跳過訊息的 proposal 狀態，與整個系統的狀態是不一致的，需要將其刪除。

解決方案是：

 Zab 通過巧妙的設計 zxid 來實現這一目的。一個 zxid 是64位，高 32 是紀元（epoch）編號，每經過一次 leader 選舉產生一個新的 leader，新 leader 會將 epoch 號 +1。低 32 位是訊息計數器，每接收到一條訊息這個值 +1，新 leader 選舉後這個值重置為 0。這樣設計的好處是舊的 leader 掛了後重啟，它不會被選舉為 leader，因為此時它的 zxid 肯定小於當前的新 leader。當舊的 leader 作為 follower 接入新的 leader 後，新的 leader 會讓它將所有的擁有舊的 epoch 號的未被 COMMIT 的 proposal 清除。