zookeeper集群中需要通過FastLeader選舉算法嫩絮。Paxos算法 來選取頭結點。由于這個特性诈乒，某個結點故障時罩扇，要耗費時間重新進行header選取，故zk在分布式CAP理論中保證的是CP(一致性和分區(qū)容錯性)怕磨。而spring cloud的eureka集群保證的是AP(高可用和分區(qū)容錯性)
一致（所有節(jié)點數據一致）喂饥，有頭（一個leader，所有客戶端連接操作通過leader完成）肠鲫，數據數（樹結構）
應用場景：
配置一致员帮。集群的配置文件統(tǒng)一管理。在zookeeper上記錄配置信息导饲，zookeeper上的記錄更改的時候捞高，會通知所有在其上面注冊過的系統(tǒng)（觀察者模式—observer）.達到統(tǒng)一管理的目的；
HA（High Availability）高可用集群啟動時渣锦，master節(jié)點在zookeeper上注冊（分為持久化節(jié)點硝岗，臨時性節(jié)點--在連接斷開后消失，此場景用臨時性節(jié)點）--active袋毙，有另外一臺服務器監(jiān)聽該master節(jié)點的狀態(tài)—standBy型檀，一旦發(fā)現其消失（由于建立的是臨時性節(jié)點，一開始的master斷開后听盖，該節(jié)點會消失）胀溺，立刻補位裂七，把自己注冊到zookeeper上變?yōu)閙aster提供服務，掛掉的節(jié)點再次啟動時仓坞，發(fā)現已經存在master背零，自己變?yōu)轭A備服務器—standBy，監(jiān)控狀態(tài)master的狀態(tài)无埃∽叫耍客戶端請求時先在zookeeper中找active的節(jié)點，然后再請求該節(jié)點录语。該業(yè)務即為主備動態(tài)切換倍啥；
pub/sub發(fā)布者，訂閱者澎埠。發(fā)通知虽缕，觀察者模式。
nameserver: rocketMQ在3.2版本之前使用zookeeper來實現服務發(fā)現
load balance負載均衡蒲稳。
分布式鎖
zookeeper 底層API中的關鍵點
zookeeper watch事件是一次性的氮趋。watcher是持續(xù)性的。 watch的特性：一次性江耀、客戶端串行執(zhí)行剩胁、輕量。
一次性：對于ZK的watcher祥国，zookeeper有watch事件昵观，是一次性觸發(fā)的，發(fā)生改變時舌稀，通知監(jiān)聽的客戶端啊犬，監(jiān)聽事件消失，需要每次重新設置監(jiān)聽壁查。
客戶端串行執(zhí)行：watch的回調是順序執(zhí)行的觉至。需要做回調。
輕量：watchedEvent是整個watch通知機制的最小單元睡腿，只包含通知狀態(tài)语御，事件類型和節(jié)點路徑三部分。不會有具體的內容席怪，比如nodeDataChanged事件应闯，zookeeper只會通知客戶端指定節(jié)點的數據發(fā)生了改變，需要客戶端自己去獲取具體的內容何恶。
-
zookeeper安裝過程中遇到的小坑：
外網訪問不通：1.防火墻孽锥。2./etc/hosts下的localhost刪除。
