Zookeeper作為Dubbo生態的默認註冊中心，已經被廣泛使用。雖然阿裏後來生產了nacos，但不可否認的是，ZK仍然是壹個優秀的開源產品，也是壹個優秀的註冊中心替代品。
ZK有許多特點。本文主要介紹ZK的選拔過程(後宮有三千美人，我就寵妳壹個人了)。
要說選擇主人的過程，首先要了解ZK有哪些節點，這些節點起什麽作用。
ZK自己的節點主要分為三類:
領導:主要負責寫數據。如果半數以上同意，則播出進行寫作；
跟隨者:主要負責查詢請求和向領導發送寫請求，參與選舉和寫投票；
觀察:它還負責查詢請求，並向領導發送寫請求。它不參與投票，只是被動地接收結果。
獲得過半票數成為領袖節點。
凡事都有規律，好的更壞，壞的更壞，世上沒有痛苦，痛苦是妳自己尋找的結果，海燕，妳可以吃點心了，唉，妳已經誤入歧途了。
ZK比較有三個指標或三個維度:
(1)任期
(2)交易ID(交易id ID(ZK)
(3)節點數量(集群中每個節點的數量)
根據以上三個指標可以得出最終結論:選擇期限大的，同壹期限交易ID大的，前兩個相同，節點數大的。
就這麽簡單？是的，規則就是這麽簡單，但源代碼仍然如此混亂。
源代碼看起來比較枯燥，但是作為壹個手藝人，怎麽能不知道怎麽做呢？我們先整理壹下代碼流程，這樣可以更好的看到第四部分。
節點先給自己投票，然後廣播。
消息由節點的內部循環接收。
接到消息後
如果消息為空，請重新發送消息或建立連接。
如果消息不為空，並且消息接收者和投票領導者是合法節點，請繼續執行以下步驟。
如果該節點是壹個查找節點
根據當前節點的投票與接收到的投票的比較，決定是否再次發送投票，並記錄投票結果。
判斷每次記錄的投票數，超過壹半則設置節點狀態。
選主的邏輯從lookForLeader開始，就像金字塔的第壹塊磚。再來看lookForLeader，ZK選主的第壹塊磚。我們第壹次看源代碼的時候，壹定要抓住主線忽略從線，等主線完全理清之後再處理從線，不然會陷入迷宮。
這是主要的投票代碼。看看裏面的筆記:
更新投票或表決的方法如下:
發送通知的方法是:
花開的時候，她在灌木叢裏笑，信息已經發出去了。該是收選票的時候了。接收選票的代碼也在lookForLeader中:
繼續討論代碼，檢查發送投票節點的狀態。從本文第壹章我們知道，觀察節點不參與投票，而是轉發寫請求和被動接收數據，並負責查詢請求，所以從代碼中我們也可以看到:
當發送投票的節點狀態為跟隨和領先時，表示發送節點已經當選，所以處理方法的邏輯是壹樣的。這部分限於篇幅太長，暫時不深入討論。有興趣的朋友可以私信或者加我微信號M _ P _ E _ D。
最後是亮點。讓我們來看看處於查找狀態的代碼:
先說totalOrderPredicate方法，它實際上是選舉領袖規則的實現。
路漫漫其修遠兮，行之必來，行之不止，未來可期，加油。