zookeeper 是什麼
zookeeper是一個分佈式服務管理框架，基於觀察者設計模式，他負責管理和存儲大家都關心的信息，並且接受觀察者的觀察監控，一旦數據節點發生變化，zookeeper就負責通知註冊的觀察者。總體來說就是zookeeper就是分佈式文件系統數據庫+通知機制。具有的特性包括：
- 分佈式中只有一個leader，但有多個follower
- 集羣中只要有半數以上的節點存活，zookeeper就可以提供服務
- 數據全局一致：ZAB協議保證每一個server都保存一樣的數據，client無論鏈接哪一個server 都讀取的副本一樣
- 有序執行：來自同一個client的更新或操作
- 事務原子性：一次成功或失敗。
- 實時性：一定的時間內，可以看到最新的數據。
zookeeper 數據結構
數據結構就是一個文件系統的路徑，也類似一個樹模型，最上層是一個root節點，然後在root節點下新建節點ZNode，並且大小是1M，並且同級下不允許有相同的ZNode節點，因爲zookeeper要通過root到ZNode的路徑做唯一標識。
選舉機制：半數以上機制
在安裝分佈式zookeeper的時候，每臺機器都有一個myid作爲標識符，當服務器一臺一臺都啓動的時候，會選擇myid最大的投票作爲leader，
目前有5臺服務器，每臺服務器均沒有數據，它們的編號分別是1,2,3,4,5,按編號依次啓動，它們的選擇舉過程如下：
（1）服務器1啓動，給自己投票，然後發投票信息，由於其它機器還沒有啓動所以它收不到反饋信息，服務器1的狀態一直屬於Looking。
（2）服務器2啓動，給自己投票，同時與之前啓動的服務器1交換結果，由於服務器2的編號大所以服務器2勝出，但此時投票數沒有大於半數，所以兩個服務器的狀態依然是LOOKING。
（3）服務器3啓動，給自己投票，同時與之前啓動的服務器1,2交換信息，由於服務器3的編號最大所以服務器3勝出，此時投票數正好大於半數，所以服務器3成爲領導者，服務器1,2成爲小弟。
（4）服務器4啓動，給自己投票，同時與之前啓動的服務器1,2,3交換信息，儘管服務器4的編號大，但之前服務器3已經勝出，所以服務器4只能成爲小弟。
（5）服務器5啓動，後面的邏輯同服務器4成爲小弟。
由於網絡問題，其實廣播投票結果時會帶上類似時間戳的zxid屬性，防止過期的廣播投票影響選舉。
於是一般集羣規模都是奇數，因爲5臺、6臺掛掉3臺機器都會使服務不可用，所以沒必要多部署一臺機器，一般都奇數就可以。考慮到一個leader和多個follower ，那麼集羣至少3臺機器。
監聽原理
單獨一個main方法來負責監聽：
- 監聽路徑
- 監聽節點數據
這個main線程會創建一個zkclient，它會負責監聽，其中main線程還有一個process方法，來處理監聽變化後的動作。
問題探索
1、腦裂問題
腦裂是原本一個集羣，由於網絡問題導致集羣變爲了兩個子集羣，網絡相互隔離，無法通信，從而變爲兩個集羣，但zookeeper不存在這個問題，因爲集羣個數是奇數，且要求超過半數存活纔可以提供服務，如果分成兩個子集羣，肯定有一個子集羣的個數不超過半個，整個子集羣無法提供服務。所以zookeeper沒有腦裂問題。
應用場景
- 服務器上、下線
節點上掛着IP節點，服務器失去服務了，節點就下線了。 - 統一命名
域名節點下掛着IP地址 - 統一配置管理
配置信息寫入znode中，其他服務來監聽這個節點，節點有變更，就作出相應的讀取配置信息的操作。 - 服務發現
- 集羣管理
znode的互相監聽，可以幫助知道集羣信息
優點
-
可靠存儲系統：設計最初的需求之一，也是ZK特性中實現最好的部分，作爲可靠存儲ZK基本沒出現過問題，僅此一項就可保證其的流行。
-
通知回調機制：通過創建節點與設置Watcher可以很方便的建立回調通知。ZK的所有應用都基於這個特性，沒有這個機制那麼機器監控相關的應用都不能處理，也就不會誕生後來在服務註冊發現相關的使用方法。實際上爲分佈式系統提供節點間回調通知方法的系統真的很少，甚至可能只有ZK（大家可以提供一些其他答案？）
-
連接狀態維護：ZK自動維護了客戶端所在的應用與服務器通信連接狀態的變化，可以比較簡單地維護系統中的成員通信情況。主要是不需要自己再去處理麻煩的通信狀態監控問題，比如斷線後自動釋放節點併產生回調。
-
文件系統模型：提供文件接口模型而不是鎖接口，更具通用性。文件系統模型中文件與目錄的概念可以映射多種含有層級關係的其他模型
-
自增長序列：這點包含了鎖的本質，但是因爲zk的模型設計導致判斷與仲裁需在客戶端進行
-
同步：數據在各個server之間同步
-
有序操作：zk本身的操作都是有序的操作。
缺點
-
不是高可用
zookeeper是數據一致性的有利代表項目，cap理論中的滿足CP條件的，網絡隔離導致的某個時刻zookeeper將處於不可用，數據不一致問題常有發生，實際理論中 -
選舉機制太慢
一旦出現網絡隔離，zookeeper就要發起選舉流程。zookeeper的選舉流程通常耗時30到120秒，期間zookeeper由於沒有master，都是不可用的。對於網絡裏面偶爾出現的，比如半秒一秒的網絡隔離，zookeeper會由於選舉過程，而把不可用時間放大幾十倍。 -
qps有限
大概一萬多，很多需要自主緩存地址，或者對其二次開發，規模增大需要同步到更多機器 tps 會下降 ，那麼這就意味zk的集羣不能很大，這就陷入了一個死循環，導致集羣整體qps tps 都是有上限的大概5w到頂啦。而且寫、讀性能很差，讀要等寫完成。一旦扛不住壓力就會改掉，又要需要選舉，這就是死循環。 -
Zookeeper不能保證跨session的強一致性
最終一致性，同session 循序一致性，比如session-A寫入數據，session-B未必能讀到；或者說，我改了某個節點，這時候網絡抖了，導致 session 超時；重建新 session 可能無法讀到之前的數據；這樣機會導致難以避免的數據不一致。 -
原生api 比較難用，客戶端也比較難用
-
監控信息很少
實際一點的應用
1、kafka 中zk應用
- kafka使用zookeeper來實現動態的集羣擴展，不需要更改客戶端（producer和consumer）的配置。broker會在zookeeper註冊並保持相關的元數據（topic，partition信息等）更新。
- 而客戶端會在zookeeper上註冊相關的watcher。一旦zookeeper發生變化，客戶端能及時感知並作出相應調整。這樣就保證了添加或去除broker時，各broker間仍能自動實現負載均衡，這裏的客戶端指的是Kafka的消息生產端(Producer)和消息消費端(Consumer)。
- Producer端使用zookeeper用來"發現"broker列表,以及和Topic下每個partition的leader，建立socket連接併發送消息。也就是說每個Topic的partition是由Lead角色的Broker端使用zookeeper來註冊broker信息，以及監測partition leader存活性，
- Consumer端使用zookeeper用來註冊consumer信息,其中包括consumer與topic的關係，consumer消費的partition列表等，同時也用來發現broker列表，並獲取消息的偏移量。
0.8版本kafka支partition級別的replication，所以Kafka負責選出一個Broker節點作爲controller來在一個partiiton內副本間進行Leader選舉，維護出一個ISR；新版本考慮到zookeeper性能問題，已經弱化作用了。
參考博客
ZooKeeper數據不一致的定位過程 (3.4.11)
zookeeper缺點
kafka-zk
Apache Kafka中Zookeeper的角色
Zookeeper的優點與侷限性