zookeeper概念
1. zookeeper是一個分布式的 開源的，分布式應用程序的協調服務，zookeeper翻譯過來就是動物管理員，它用來管理Hadoop(大象)，Hive(蜜蜂)，pig(小豬)的管理員 簡稱zk
zookeeper提供的功能主要包括：
配置管理
分布式鎖
集群管理
2. zookeeper是一個樹形目錄服務(文件系統)，每一個節點都會保存自己的數據和節點信息
節點可以分為四大類
持久化節點
臨時節點 -e
持久化順序節點 -s
臨時順序節點 -es
常用命令
1.連接到zookeeper服務器
進入到bin目錄 執行 ./zkCli.sh ip:port
2.查看節點和子節點
ls /xxx
3. 創建節點並存放數據
3.1 create /app1 hello 此時創建的是持久化節點
3.2 create -e /app1 此時創建的是臨時節點 當前會話斷開，節點就消失了
4.獲取數據
get /app1 輸出:hello
5. 設置數據
set /app1 nihao (此時 nihao會把上面的hello覆蓋)
6. 刪除節點 delete /app1
ZK分布式鎖
核心：當客戶端想要獲取鎖，就創建節點，釋放鎖就刪除。
1. 客戶端獲取鎖時，在lock(隨便取的名字)節點下創建臨時順序(如果是持久化節點，獲取鎖的節點如果宕機了，鎖就不會被釋放/刪除了)節點。
2. 然后獲取lock下面所有的子節點(節點是樹形結構嘛)，客戶端獲取到所有的子節點之后，如果發現自己創建的子節點序號最小，就認為該客戶端獲取到了鎖。使用完鎖后，將該節點刪除。
3. 如果發現自己創建的節點並非lock所有子節點中最小的(1 2 3獲取到了2 )，說明自己還沒有獲取到鎖，此時客戶端需要找到比自己小的那個節點(2)，同時對其注冊事件監聽器，監聽刪除事件。
4. 如果發現比自己小的節點被刪除(2)，則客戶端的watcher會收到相應的通知，此時再次判斷自己創建的節點是否是lock子節點序號最小的，如果是則獲取到了鎖，如果不是則重復上面的步驟，繼續獲取比自己小的一個節點，並注冊監聽。
java curator API鎖的實現
lock.acquice(3,TimeUnit.SECONDS); //獲取鎖 獲取不到等待3s鍾
......
lock.release(); //用完釋放鎖
參考redis分布式鎖：
https://www.cnblogs.com/ssskkk/p/10324158.html#_label2
ZK集群
配置集群：
1.在每個zookeeper的data目錄下創建一個myid文件，內容分別是1、2、3...這個文件就是記錄每個服務器的id。
2.在每一個zookeeper的zoo.cfg配置客戶端訪問端口(clientPort)和集群服務器IP列表
leader選舉機制：
ServerId:服務器id,比如有三台服務器，編號分別是1,2,3。編號越大在選擇算法中的權重越大。
Zxid：數據ID 服務器中存放的最大數據ID，值越大說明數據越新，在算法選舉中 數據越新權重越大。
ZooKeeper節點狀態改變的每一個操作都將使節點接收到一個Zxid格式的時間戳，並且這個時間戳全局有序。
也就是說，每個對節點的改變都將產生一個唯一的Zxid。
如果Zxid1的值小於Zxid2的值，那么Zxid1所對應的事件發生在Zxid2所對應的事件之前。
在Leader選舉中：如果某台zookeeper獲得超過半數的選票，則此Zookeeper就可以成為Leader了。
ZK集群角色
Leader領導者：
1.處理事物請求(增刪改)
2.集群內部各服務器的調度者
Follower跟隨者：
1.處理客戶端非事物請求(查詢)，轉發事物請求給Leader服務器
2.參與Leader選舉投票
Observer觀察者(分擔Follower壓力)：
1.處理客戶端非事物請求(查詢)，轉發事物請求給Leader服務器
zookpeer 和 redis 集群內一致性協議及選舉對比
一致性問題：分布式環境引入副本機制后，不同數據節點間可能出現的，並無法依靠計算機應用程序自身解決的數據不一致情況。
簡單的講，數據一致性就是指在對一個副本數據進行更新的同時，必須確保也能夠更新其他的副本，否則不同副本間的數據將不再一致。
引用文章：https://www.cnblogs.com/stateis0/p/9062133.html
zookeeper 選舉和數據同步使用的都是zab算法
redis 的哨兵在崩潰選舉的時候采用的是 raft算法，但是redis在做主從數據同步的時候，用的是異步方法。
所以redis的性能比較高，但一致性不如zookeeper
下面簡單介紹這幾個算法：
Paxos算法：
paxos算法是Lamport宗師提出的一種基於消息傳遞的分布式一致性算法，使其獲得2013年圖靈獎。(其中決策模型是根據希臘城邦發布律法的議會模型去制定的)
其中有兩階段提交，一階段提交：告訴其他議員 我們要討論某個預案。二階段提交：將議案內容給到其他議員。
raft協議：
基於Paxos算法，但更容易理解與實現
對於日志不一致的現象，Raft通過跟隨者 強制復制領導者的日志來保證的。
客戶端的一條指令到達，領導者會為這條指令創建一條日志目錄，並且並行發送到其他跟隨者。
在領導選舉的時候，只能讓安全的節點當Leader，所謂安全，就是對應節點擁有當前領導者已經提交的所有日志。
zab協議：
專門為zookeeper設計的一個一致性算法
Redis ReadLock：
基於 Redis 實現分布式鎖的方式名叫 Redlock，此種方式比原先的單節點的方法更安全。
參考：https://zhuanlan.zhihu.com/p/111354065?from_voters_page=true
注冊中心集成
TODO