參考：https://blog.csdn.net/qq_21125183/article/details/86484213
ZK系列文章：https://blog.csdn.net/qq_21125183/category_8609552.html
zk基礎看這里： https://blog.csdn.net/wypblog/article/details/103268246
Zookeeper中的角色主要有以下三類，如下表所示：
zookeeper本身支持單機部署和集群部署，生產環境建議使用集群部署，因為集群部署不存在單點故障問題，並且zookeeper建議部署的節點個數為奇數個，只有超過一半的機器不可用整個zk集群才不可用。zookeeper集群中主要有兩個角色leader和flower，每個客戶端可以連接集群中的任何一個zookeeper節點，同時從其上面read信息，但是針對write操作，flower節點會轉發給leader，由leader負責原子廣播，從而保證集群中各個節點的數據一致性，zookeeper中規定只有當多余一半的節點同步完成整個write操作才算完成。也就是說可能會有少於一半的數據不是新數據，因此zookeeper中不是強一致性而是實現的最終一致性。但是客戶端可以使用sync來強制讀取最新的數據。
最終一致性：讀數據時，有可能會臟讀。比較推薦watch的方式，實現數據的及時生效。
zk是 leader -follower機制，所有的寫操作是leader廣播通知到所有follower，有一半確認即可。那么廣播肯定是不可靠的，萬一有的follower沒有操作本地數據，所有打到這台follower的請求讀到的不是臟數據了嗎？
1、zk保證的是順序一致性，短時間是會有臟讀的產生。leader會為每一個follower創建一個廣播隊列，保證消息的順序性。folower端：在下一個消息到來時，必已經順序操作之前的消息了。
2、如果一個客戶端將Znode z的值更新為a，在之后的操作中，它又將z的值更新為b，則沒有客戶端能夠在看到z的值是b之后再看到值a；因為客戶端也會保存一個它見過的最大的 zxid，如果讀取的時候，如果客戶端發現 本地 zxid 比 server 端的最大 zxid 大，則拒絕，client 會自動重連到其他server。所以client可能會讀到臟數據，但不會讀到實時數據后，還會再讀到臟數據。
3、如果是廣播同步數據的過程中，集群崩潰了。集群會進入投票狀態，會通過投票機制選出一個commit最高（數據最新）的zk節點，然后其他follower 都會同步數據到最高commit（數據最新）。
zk基礎看這里： https://blog.csdn.net/wypblog/article/details/103268246