如何理解zookeeper？
1、背景
在一個系統中，多個服務可能都會請求一個資源，多個服務同時請求時可能存在髒數據的問題，爲了避免這種問題我們需要對多個服務進行上鎖，可以通過調度算法來規範服務之間的請求次序。這樣其中一個服務請求時，其它服務就等待。在單個系統中可以直接這樣實現，但是對於分佈式系統不一樣。
2、產生
在分佈式系統中通過網絡連接多個服務，多個服務同時去請求一個資源，那麼就需要特定的角色來管理服務的請求次序，就像單個系統中的調度算法一樣，而這樣的角色就是zookeeper。
3、使用流程
在分佈式系統中多個服務向zookeeper中註冊，註冊之後進行通過zookeeper統一管理，zookeeper來對服務的請求進行加鎖，這樣一個服務請求資源時，對這部分資源進行加鎖，其它服務不能請求，當服務處理完資源釋放鎖之後其它服務才能進行。這就是zookeeper在分佈式系統中實現的分佈式鎖的思想，這是一種分佈式協調技術，協調各個服務的關係以及請求。
所以zookeeper主要實現的是：分佈式一致性問題以及分佈式鎖的實現。
4、介紹
zookeeper介紹：
- 理解節點：zookeeper中的節點可以理解爲B-Tree模型，每個節點存儲的是自己的數據以及節點的信息，
- 節點分爲：臨時節點、永久節點
- 臨時節點的生命週期依賴於會話、臨時節點不允許有子節點
- 永久節點不依賴於會話，在執行刪除操作時纔會刪除永久節點
- 節點在創建時都會維護一個
stat的數據結構，裏面存儲了節點的狀態信息：
5、詳解
- 對於每個節點都要進行一個監聽，在zookeeper中有
watch監聽器，watch監聽每個節點的變化，節點的增刪改都會出發watch，watch被觸發就會向客戶端發送一條通知信息。 - watch中提供了有序的一致性保證。
- watch機制：zookeeper服務器、客戶端線程、watchmanager
當客戶端向zookeeper服務中註冊同時會向watchmanager中存儲一個watch對象
，zookeeper服務器觸發了watch，向客戶端發送通知，客戶端從watchmanager中取出watch對象進行回調，告訴zookeeper服務器收到了通知。
6、分佈式鎖實現
目的：解決分佈式系統中的單點故障問題
場景：分佈式系統中採用主從模式，一個主節點連接多個從節點，主節點服務分發任務，從節點服務處理任務，若主節點發生故障，則系統癱瘓。
- 傳統的解決方式：通過增加一個備用主節點，備用主節點和主節點發送ping消息和ack確認信息，判斷主節點是否掛掉。
但是會出現一個問題就是ack確認信息因爲網路故障沒發送成功，導致備用主節點以爲主節點已經掛掉（其實沒掛掉）。 - 通過zookeeper解決：設置兩個主節點001和002，都向zookeeper中註冊，zookeeper的註冊機制（paxos算法會推舉一個master）會推舉一個節點爲主節點，例如爲001爲主節點，002爲備用節點。
若主節點掛掉，zookeeper中通過監聽節點信息來發現主節點掛掉了，那麼會再進行推舉的方式，002被推舉爲主節點
若主節點恢復，那麼監聽到001恢復，則繼續執行推舉的方式，推舉一個主節點出來，另一個爲備用節點。
7、總結
- zookeeper通過將服務註冊到節點中，通過watch來監控節點的狀態，間接的監控了服務的狀態，就能夠及時的知道服務的狀態，然後進行判斷處理。避免了網絡波動引發的服務之間監控出問題。
- 如可以通過創建臨時節點來建立心跳檢測機制。如果分佈式系統的某個服務節點宕機了，則其持有的會話會超時，此時該臨時節點會被刪除，相應的監聽事件就會被觸發。
- 分佈式系統的每個服務節點還可以將自己的節點狀態寫入臨時節點，從而完成狀態報告或節點工作進度彙報。
- 通過數據的訂閱和發佈功能，Zookeeper還能對分佈式系統進行模塊的解耦和任務的調度。
- 通過監聽機制，還能對分佈式系統的服務節點進行動態上下線，從而實現服務的動態擴容。