zookeeper就是分佈式的註冊中心
配置文件
tickTime=2000 initLimit=10 syncLimit=5 dataDir=/app/soft/zookeeper-3.4.6/data （換成真實輸出目錄） clientPort=2181
#tickTime：這個時間是作爲 Zookeeper 服務器之間或客戶端與服務器之間維持心跳的時間間隔，也就是每個 tickTime 時間就會發送一個心跳，以毫秒爲單位。 #initLimit：LF初始通信時限，集羣中的follower服務器(F)與leader服務器(L)之間初始連接時能容忍的最多心跳數（tickTime的數量） #syncLimit：集羣中的follower服務器與leader服務器之間請求和應答之間能容忍的最多心跳數（tickTime的數量）。 #dataDir：顧名思義就是 Zookeeper 保存數據的目錄，默認情況下，Zookeeper 將寫數據的日誌文件也保存在這個目錄裏。 #clientPort：這個端口就是客戶端連接 Zookeeper 服務器的端口，Zookeeper 會監聽這個端口，接受客戶端的訪問請求。 #dataLogDir：日誌文件目錄，Zookeeper保存日誌文件的目錄 #服務器名稱與地址：集羣信息（服務器編號，服務器地址，LF通信端口，選舉端口），規則如：server.N=yyy:A:B #其中N表示服務器編號，YYY表示服務器的IP地址，A爲LF通信端口，表示該服務器與集羣中的leader交換的信息的端口。B爲選舉端口，表示選舉新leader時服務器間相互通信的端口（當leader掛掉時，其餘服務器會相互通信，選擇出新的leader）。一般來說，集羣中每個服務器的A端口都是一樣，每個服務器的B端口也是一樣。但是當所採用的爲僞集羣時，IP地址都一樣，只能時A端口和B端口不一樣。 server.1= 127.0.0.1:2888:3888 server.2= 127.0.0.1:2889:3889 server.3= 127.0.0.1:2890:3890 #server.A=B:C:D 其中A是一個數字，代表這是第幾號服務器；B是服務器的IP地址；C表示服務器與羣集中的“領導者”交換信息的端口；當領導者失效後，D表示用來執行選舉時服務器相互通信的端口。
zkServer.sh status可以查看該服務器是什麼類型的服務器
1.節點
主要分爲臨時節點和永久節點，其中又分爲無序和有序
2.選舉
選舉服務器最好是基數，因爲zookeeper的可用性是隻要在一半以上服務器可用就整體可用，偶數個比及數個更浪費，5個服務器可損失的服務器是2個，6個服務器可損失的服務器也是兩個，過半原則導致偶數服務器看上去有些浪費。
2.1選舉在leader和follower中進行，比較zxid，如果zxid一致則比較myid，myid是可以設置的，在zoo.cfg中server.0=ip:port1:port2
其中0就是myid，ip就是各個服務器的ip地址，port1是leader和followerd的通信端口，port2是leader和follower的選舉端口
在 ZAB 協議的事務編號 ZXID 設計中，ZXID 是一個 64 位的數字，其中低 32 位可以看作是一個簡單的遞增的計數器，針對客戶端的每一個事務請求，Leader 都會產生一個新的事務 Proposal 並對該計數器進行 + 1 操作。
而高 32 位則代表了 Leader 服務器上取出本地日誌中最大事務 Proposal 的 ZXID，並從該 ZXID 中解析出對應的 epoch 值，然後再對這個值加一。
高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事務的唯一性。同時，也能讓 Follwer 通過高 32 位識別不同的 Leader。簡化了數據恢復流程。
基於這樣的策略：當 Follower 鏈接上 Leader 之後，Leader 服務器會根據自己服務器上最後被提交的 ZXID 和 Follower 上的 ZXID 進行比對，比對結果要麼回滾，要麼和 Leader 同步。
3.腦裂
如果leader和兩個follower在一個網絡區域，另外三臺follower在一個網絡區域，當兩個網絡區域斷掉的時候，實施重新選舉。
3.1情況一，選舉出新leader後聯通，則使用新leader
3.2情況二，在選舉時原有leader聯通了，則使用原有leader
4.同步
ZAB協議是爲zookeeper專門設計的一種支持奔潰恢復的原子廣播協議。
ZAB協議主要的作用在於三個方面1、選舉出leader;2、同步節點之間的狀態達到數據一致；3、數據的廣播。
假設1：Leader 在複製數據給所有 Follwer 之後崩潰，怎麼辦？
假設2：Leader 在收到 Ack 並提交了自己，同時發送了部分 commit 出去之後崩潰怎麼辦？
針對這些問題，ZAB 定義了 2 個原則：
- ZAB 協議確保那些已經在 Leader 提交的事務最終會被所有服務器提交。
- ZAB 協議確保丟棄那些只在 Leader 提出/複製，但沒有提交的事務。
所以，ZAB 設計了下面這樣一個選舉算法：
能夠確保提交已經被 Leader 提交的事務，同時丟棄已經被跳過的事務。
針對這個要求，如果讓 Leader 選舉算法能夠保證新選舉出來的 Leader 服務器擁有集羣總所有機器編號（即 ZXID 最大）的事務，那麼就能夠保證這個新選舉出來的 Leader 一定具有所有已經提交的提案。
而且這麼做有一個好處是：可以省去 Leader 服務器檢查事務的提交和丟棄工作的這一步操作。
5.zookeeper觀察者
首先，在每一個想要成爲觀察者節點的配置文件中，你必須加入這一行：
peerType=observer 這一行告訴ZK這個服務端想要成爲觀察者。
第二，在每一個服務端的配置文件中，你必須在每一個觀察者的服務者定義那一行加入:observer。例如:
server.1=localhost:2181:3181:observer
這告訴每一個其它服務端server.1是一個觀察者，並且他們應該不要求它來投票。這是所有你需要增加的配置。現在你可以連接上它就好像它是一個普通的追隨者。試試。通過運行下面的命令：
bin/zkCli.sh -server localhost:2181
這裏的localhost:2181是觀察者的主機名和端口號，正如在每一個配置文件中指定的那樣。你應該可以看到一個命令行提示，通過它你可以發起像ls的命令來查詢ZK服務。
6.zookeeper分佈式鎖
https://www.jianshu.com/p/5d12a01018e1
7.調用