關於Zookeeper的原子廣播和崩潰恢復

1.zab(zookeeper atomic broadcast)是一套專門為zookeeper設計的用於原子廣播和崩潰恢復的協議

2.zab基於2pc演算法進行設計，利用了過半性和paxos演算法進行了改進

atomic broadcast - 原子廣播

1.作用：保證資料一致性。(強一致性+最終一致性)

2.原子廣播基於2pc進行設計的

3.2pc - two phase commit - 二階段提交

⑴請求階段：當協調者收到請求之後，不會立即決定是否要執行這個請求，而是會將請求**給每乙個參與者，等待參與者的反饋資訊

⑵提交階段：如果協調者收到所有參與者返回的yes，那麼會認為這個請求可以執行，那麼就會命令所有參與者執行這個請求

⑶中止階段：只要協調者沒有收到所有參與者返回的yes，那麼就認為這個請求不能執行，就會拒絕執行這個請求

4.2pc要麼執行請求-提交階段，要麼執行請求-中止階段

5.2pc的核心思想是"一票否決"

6.2pc的優勢和劣勢一樣明顯：

2pc的優勢在於理解和實現過程都相對簡單；

2pc的劣勢在於非常受外界環境(尤其是網路環境)影響

7.在實際開發中，分布式系統很少直接採用2pc演算法，而往往都是在2pc的基礎上來進行改變。其中zookeeper的原子廣播就是基於2pc加入了過半性來進行改進

8.原子廣播的流程

⑴leader接收到請求之後，先把這個請求記錄到本地的日誌檔案log.***中。log.***檔案的位置由datalogdir屬性來決定

⑵如果記錄失敗，則直接報錯；如果記錄成功，則leader會將請求放到佇列中傳送給每乙個follower，等待follower的反饋資訊

⑶follower收到佇列之後，會將請求從佇列中一一取出，然後記錄到本地的日誌檔案log.***中。如果記錄成功，則follower會給leader返回乙個yes；如果記錄失敗，則follower會給leader返回乙個no

⑷如果leader收到一半及以上的follower返回的yes，則認為這個請求可以執行，那麼leader命令所有的節點執行剛才的請求(事務提交)；如果leader沒有收到一半的yes，則認為這個請求不能執行，那麼leader命令所有的節點刪除剛才的請求(事務回滾)

9.如果follower記錄日誌失敗，但是還需要執行請求的時候，這個時候follower會給leader傳送請求，leader收到請求之後，會將請求放到佇列中再次傳送給follower，follower收到佇列之後，會將請求先記錄到日誌中，然後再執行這個請求。如果這個過程中，日誌再次記錄失敗，則follower會重新傳送請求

10.follower返回no的可能 - 日誌記錄失敗

⑴日誌檔案被占用

⑵磁碟已滿 - 實際生產過程中，如果磁碟滿了，那麼一般會進行壓縮或者清理

⑶磁碟損壞

11.當乙個節點重新連入集群之後，這個節點會先尋找自己的最大事務id，然後將自己的事務id傳送給leader。 leader在收到請求之後，會比較最大事務id是否一致。如果不一致，則leader會將欠缺的操作放到佇列中返回給follower，要求follower補齊事務。在事務補齊期間，這個follower不會對外提供服務

1.在zookeeper中，當leader宕機之後，這個zookeeper不會停止服務，而是會選舉出乙個新的leader，這個過程稱之為崩潰恢復

2.作用：保證集群的高可用 - 分割槽容忍性

3.zookeeper會給每乙個leader分配乙個全域性遞增的編號，稱之為epochid。當leader被選舉出來之後，這個leader會將自己的epochid分發給每乙個follower。每乙個follower收到epochid之後，會將這個epochid儲存到本地檔案acceptedepoch中

4.在zookeeper集群中，事務id實際上由64位二進位制(16位十六進製制)構成。其中前32位對應的epochid，後32位對應的是實際的事務id。例如事務id為0x400000002表示第4任執行的第2個寫操作

關於Zookeeper的原子廣播和崩潰恢復

Zookeeper原子廣播Zab

zookeeper 原子廣播機制

關於zookeeper的討論

關於Zookeeper的原子廣播和崩潰恢復

Zookeeper原子廣播Zab

zookeeper 原子廣播機制

關於zookeeper的討論

相關推薦