ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分佈式同步、組服務等。
順序一致性：客戶端的更新將按順序應用（主節點負責寫）
原子性：更新要麼成功要麼失敗
單個系統映像：無論客戶端連接到哪個服務器，客戶端都將看到相同的服務視圖。也就是說，即使客戶端故障轉移到具有相同會話的其他服務器，客戶端也永遠不會看到系統的較舊視圖
可靠性：應用更新後，此更新將一直持續到客戶端覆蓋更新爲止。
及時性：確保系統的客戶視圖在特定時間範圍內是最新的。
zookeeper 使用的是最終一致性。作爲協議協議的一部分，來自客戶端的所有寫請求都轉發到稱爲領導者的單個服務器。
zk的數據存在內存，用磁盤來保存日誌。
角色：
leader：主節點，負責數據的寫入
follower：從節點，負責數據的讀取
observer：功能一就如同他的名字，只是一個觀察者，對leader和follower的工作進行觀察監聽。
功能二就是動態擴展zookeeper集羣，而又不影響集羣的性能，接收客戶端連接，執行leader更新系統狀態的命令，不影響集羣的性能是因爲觀察者節點不參與投票，即使是觀察者節點宕機了，對集羣的運行狀態沒有影響。
只有follower 才能選舉。follower越少選舉速度越快。其餘的爲observer即可，放大查詢能力。
zookeeper 需要啓動前在配置文件中配置好有那些節點，以及端口。例如 server.1=zoo1:2888:3888 3888 是用來節點間傳遞消息的。過半選舉推薦機制。 server.後面的值越大越容易選舉爲主節點。
zookeeper目錄節點分類：
臨時節點 和 永久節點
臨時節點：zookeeper有一個session的概念，當session斷開，創建的臨時節點對應消失。
永久節點：一直存在，相當於持久化。
Persistent是臨時節點、
Persistent_sequential是臨時有序節點。如00000、000001.....
Ephemeral是永久節點、
Ephemeral_sequential是永久有序節點
CreateMode.PERSISTENT_SEQUENTIAL 對應命令 create -s -e /path CreateMode.PERSISTENT 對應命令 create -e /path CreateMode.Ephemeral 對應命令 create /path CreateMode.Ephemeral_sequential 對應命令 create -s /path
-s 即代表序列的意思。臨時節點不能有子節點
簡單的API
ZooKeeper的設計目標之一是提供一個非常簡單的編程界面。因此，它僅支持以下操作：
-
create：在樹中的某個位置創建一個節點
-
delete：刪除節點
-
存在：測試某個位置是否存在節點
-
獲取數據：從節點讀取數據
-
設置數據：將數據寫入節點
-
獲取子節點：獲取節點子節點的列表
-
sync：等待數據傳播
使用命令：get /目錄信息
cZxid=0x200000002 創建事務ID
mZxid=0x200000004 修改事務ID
pZxid=0x200000002 當前節點最後創建事務的ID（屬於自己的事務ID）
ephemeralOwner=64325234 當前節點歸屬的session ID
cZxid 是一個64位的數字，高32位代表leader節點id，當新的leader產生則會發生變化，低32位用來遞增。
當A連上1，產生一個sessionId，當1掛掉了，A去連接 2 。此時，2也會認A的這個sessionId。因爲zookeeper每個節點間的數據長得都是一樣的，會進行同步。包括A在1上面產生的數據。
當第一個客戶端創建一個目錄數據得到 cZxid = 0x800000a22
第二個客戶端連接並創建目錄數據得到 cZxid = 0x800000a24
新客戶端進行連接的時候會消耗掉一個 cZxid ，即 0x800000a23 被消耗掉了。
無論客戶端連入還是刪除節點等都會消耗一個事務ID
zookeeper選舉
每個節點有自己的mid，不同的zxid。
當leader掛掉後，zxid（事務ID）最新的可以獲得投票，當投票數過半可以獲得選舉。如果很多個zxid都相同，則mid最大的被選爲leader。
當選出leader後， czxid 、mxid、pzxid 的 高32位都會在上一個leader 事務ID 的基礎上+1，後續節點的操作ID會從當前leader 對應的 czxid 高32位 重新開始遞增。在這個leader之前的節點信息的事務ID保持不變，除非發生更改。
ZAB協議
一、消息廣播：過半通過
leader將客戶端的請求記錄爲一個 Proposal 提議，併爲每個follower 準備了一個fifo隊列，隊列裏面放的就是 Proposal ，所以多個 Proposal 都是順序性的。然後每個fifo 隊列裏的消息會廣播到對應的 follower去，並對 Proposal 做出 ack 反饋。當leader 收到半數（包括自己）的 ack 後，這個 Proposal 則通過了，及時其餘的follwer沒有反饋。leader 開始對所有的follower 進行通知 commit 寫入。
二、崩潰恢復：數據最全的做主
當leader進行通知的時候，如果leader掛了怎麼辦呢？
當leader掛了，follower 開始進行選舉。A 、B、C 開始拿出自己的 ZXID 選舉，ZID最大的那一個選舉成功。如果最後發現都一樣，就拿出各自的 id 選舉，最大的那一臺當選。
爲什麼ZXID最大的選舉可以成功？
ZXID 和 Proposal 掛鉤，最大的說明數據最全。ZXID是過半通過之後才代表成功寫入的，即大家都贊同的，就是說最大的ZXID是半數以上的 follower 都有的。
https://baijiahao.baidu.com/s?id=1666465070459184658&wfr=spider&for=pc
zookeeper多節點配置
修改zoo.cnf
server.1=127.0.0.1:2888:3888
server.2=127.0.0.2:2888:3888
server.3=127.0.0.3:2888:3888
server.4=127.0.0.4:2888:3888
- 2888 -- leader與follower 之間的通信
- 3888 -- leader掛掉時節點間的通信。
- 2181： 對外提供服務的端口
本機多臺的話配置：
server.1=127.0.0.1:2888:3888 server.2=127.0.0.1:2889:3889 server.3=127.0.0.1:2890:3890
mq 對比
https://blog.csdn.net/liuzhixiong_521/article/details/84849184
rabbitmq 支持exchange（交換器）功能