zookeeper集群中需要通過FastLeader選舉算法。Paxos算法 來選取頭結(jié)點。由于這個特性，某個結(jié)點故障時，要耗費時間重新進行header選取，故zk在分布式CAP理論中保證的是CP(一致性和分區(qū)容錯性)。而spring cloud的eureka集群保證的是AP(高可用和分區(qū)容錯性)
一致（所有節(jié)點數(shù)據(jù)一致），有頭（一個leader，所有客戶端連接操作通過leader完成），數(shù)據(jù)數(shù)（樹結(jié)構(gòu)）
應(yīng)用場景：
配置一致。集群的配置文件統(tǒng)一管理。在zookeeper上記錄配置信息，zookeeper上的記錄更改的時候，會通知所有在其上面注冊過的系統(tǒng)（觀察者模式—observer）.達(dá)到統(tǒng)一管理的目的；
HA（High Availability）高可用集群啟動時，master節(jié)點在zookeeper上注冊（分為持久化節(jié)點，臨時性節(jié)點--在連接斷開后消失，此場景用臨時性節(jié)點）--active，有另外一臺服務(wù)器監(jiān)聽該master節(jié)點的狀態(tài)—standBy，一旦發(fā)現(xiàn)其消失（由于建立的是臨時性節(jié)點，一開始的master斷開后，該節(jié)點會消失），立刻補位，把自己注冊到zookeeper上變?yōu)閙aster提供服務(wù)，掛掉的節(jié)點再次啟動時，發(fā)現(xiàn)已經(jīng)存在master，自己變?yōu)轭A(yù)備服務(wù)器—standBy，監(jiān)控狀態(tài)master的狀態(tài)。客戶端請求時先在zookeeper中找active的節(jié)點，然后再請求該節(jié)點。該業(yè)務(wù)即為主備動態(tài)切換；
pub/sub發(fā)布者，訂閱者。發(fā)通知，觀察者模式。
nameserver: rocketMQ在3.2版本之前使用zookeeper來實現(xiàn)服務(wù)發(fā)現(xiàn)
load balance負(fù)載均衡。
分布式鎖
zookeeper 底層API中的關(guān)鍵點
zookeeper watch事件是一次性的。watcher是持續(xù)性的。 watch的特性：一次性、客戶端串行執(zhí)行、輕量。
一次性：對于ZK的watcher，zookeeper有watch事件，是一次性觸發(fā)的，發(fā)生改變時，通知監(jiān)聽的客戶端，監(jiān)聽事件消失，需要每次重新設(shè)置監(jiān)聽。
客戶端串行執(zhí)行：watch的回調(diào)是順序執(zhí)行的。需要做回調(diào)。
輕量：watchedEvent是整個watch通知機制的最小單元，只包含通知狀態(tài)，事件類型和節(jié)點路徑三部分。不會有具體的內(nèi)容，比如nodeDataChanged事件，zookeeper只會通知客戶端指定節(jié)點的數(shù)據(jù)發(fā)生了改變，需要客戶端自己去獲取具體的內(nèi)容。
-
zookeeper安裝過程中遇到的小坑：
外網(wǎng)訪問不通：1.防火墻。2./etc/hosts下的localhost刪除。
