監聽器原理

1）Main執行緒中開啟兩個執行緒，Listerner負責監聽，Connect負責網路通訊。

2）Connect執行緒將註冊的監聽事件發給Zookeeper。

3）Zookeeper中監聽器列表發生變化就通知Listerner。

4）Listerner內部呼叫回撥函式process。

Zookeeper的選舉機制

設有5臺zookeeper，myid分別為1、2、3、4、5，依次啟動。

1）1號啟動 => 找Leader => 無 => 發起選舉 => 投1號 => 1號1票，無Leader。

2）2號啟動 => 找Leader => 無 => 發起選舉 => 投2號，同時1號發現2號比自己厲害改投2號 => 2號2票，無Leader。

3）3號啟動 => 找Leader => 無 => 發起選舉 => 投3號，同時1號和2號都發現3號比自己厲害都改投3號 => 3號3票，超過半數，3號為Leader。

4）4號啟動 => 找到Leader為3號。

5）5號啟動 => 找到Leader為3號。

如何判斷誰厲害？

1）先看zxid，誰大誰的事務新，資料就新，更應該成為Leader。（但Zookeeper大部分時間都是保持一致性的，zxid理想情況下應一致。）

2）再看myid，誰大誰厲害。

Zookeeper盡力保持資料一致性

當有資料發生修改時，Zookeeper要盡力保持全域性資料一致性。

1）客戶端向一個Server發起寫請求（寫請求是一個事務有zxid號）。

2）如果這個Server不是Leader，它會通知Leader，Leader再把寫請求廣播給所有Flower。

3）所有Zookeeper投票，如果同意則把寫請求放入待寫佇列。

4）Leader收集票數，>半數則同意寫，告知所有Server寫。原本同意的寫。不同意的直接重啟，再從Leader處同步資料。

5）最後告知Client寫成功。

正常情況下都會同意寫，何時會不同意寫？

因為網路延遲，某臺Server當前最新的zxid比傳過來的寫請求zxid大，說明已經產生資料不一致，不能再寫，再從Leader處同步資料。極端情況下Leader會不同意只能重啟，重新選舉Leader，再從Leader處同步資料。