1.談一談你對zookeep的認識？

分布式環(huán)境下，數(shù)據(jù)通過網(wǎng)絡(luò)傳輸，數(shù)據(jù)的修改和增加需要各個集群節(jié)點同步；

Zookeeper就能夠做到，它是解決數(shù)據(jù)一致性工具，它能夠在分布式環(huán)境下協(xié)調(diào)各數(shù)據(jù)資源，保證數(shù)據(jù)的一致性，可靠性。它能夠保證同一個客戶端的請求在zookeeper集群中是按照順序操作，而且是原子性操作；并且無論連接那個客戶端看到的數(shù)據(jù)都是一致的。

它是怎么做到的？

這就涉及到Zookeeper的ZAB協(xié)議、選舉機制、數(shù)據(jù)模型、底層算法等

2.ZAB協(xié)議（原子消息廣播協(xié)議）？

Zookeeper依賴zab協(xié)議來實現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，zookeeper實現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)，使用Zab協(xié)議作為數(shù)據(jù)一致性的算法；

Zab協(xié)議：

是在Paxos算法的基礎(chǔ)上改造而來的，支持崩潰恢復(fù)機制，Zookeeper使用單一的主進程leader,處理客戶端所有的請求事物，zab協(xié)議保證Leader廣播的變更序列被順序的處理：一個狀態(tài)被處理，那么它所依賴的狀態(tài)也一定被處理；Zab支持崩潰恢復(fù)，保證leader進程崩潰的時候可以重新選舉出新的leader來管理數(shù)據(jù)，保證數(shù)據(jù)的完整性一致性。

這就涉及到zookeeper的過半選舉機制？

3.Zookeeper的選舉機制？

Zookeeper中采用“過半選舉”實現(xiàn)數(shù)據(jù)的一致性，可靠性。

1）同步機制

在zookeeper中所有的事物請求都由一個主服務(wù)器（leader）處理，Leader將客戶端的請求轉(zhuǎn)換為一個事物，分發(fā)給所有的follower；同時leader按照請求更改自己的數(shù)據(jù)，follower按照leader給他們維護的編號順序同步Leader中的數(shù)據(jù)。

Leader等待follower反饋，將反饋結(jié)果標(biāo)記在“同步列表”中，當(dāng)有超過半數(shù)的follower反饋“同步完成”，leader再次向集群內(nèi)的follower廣播commint，向客戶端反饋“同步成功”； leader的責(zé)任（讀+寫+廣播），follower責(zé)任（讀+同步+反饋）；

總結(jié)：“同步機制-&兩次廣播，兩次反饋”

2）啟動選舉機制

Zab協(xié)議存在三種狀態(tài)，Looking、Following、Leading。

Zookeeper啟動的時候所有的節(jié)點都處于looking狀態(tài)，這時集群會相互發(fā)送id嘗試選舉出一個Leader，只要其中一個Looking票數(shù)過半，選舉成功，它將狀態(tài)切換為Leading狀態(tài)，其它的Looking切換為following狀態(tài)；

如果選舉不成功，重新選，直到選舉出leader為止，我們可以在配置文件中設(shè)置重新選舉的時間，第一次集群啟動，重新選舉并不影響集群工作。默認情況下，按照節(jié)點號，選除1外的第一個基數(shù)節(jié)點當(dāng)leader。

總結(jié)：“所有following都有機會，過半則成，不成在選，有默認”

3）Leader宕機選舉機制！

當(dāng)leader宕機后，集群中的每一個Follower都想當(dāng)Leader，它們都有機會，又都沒有機會。

所有的follower會相互發(fā)送ZXID，對比ZXID，選擇攜帶數(shù)據(jù)最新的follower當(dāng)leader；

具體流程：

每個follower都會攜帶（ZXID）向其它節(jié)點發(fā)送請求，選自己為leader的vote，等待回復(fù)；

Follower接收到的ZXID比自己新，更新自己的vote為持有數(shù)據(jù)最新的follower的選票，否則拒絕；

每個follower中維護著一個投票記錄表，不斷的更新自己的選票，當(dāng)某個節(jié)點的選票過半，該節(jié)點晉升為leader，選舉結(jié)束。

所有的follower跟著新的leader同步，舊eader重啟后變?yōu)閒ollower，和新leader同步。

總結(jié)：“選最新”

4）Follower宕機選舉

follower和Leader之間通過“心跳檢測”來感知對方存在狀態(tài)，follower每隔一段時間向follower發(fā)送心跳報告，證明自己還活著。心跳機制通過RPC的一個接口類的一個方法來發(fā)； 當(dāng)有過半的follower的沒有發(fā)送心跳報告，Leader切換到Looking狀態(tài)，活著的follower也隨之切換到Looking狀態(tài)，集群停止工作，開始新一輪的選舉。

4.Zookeeper的數(shù)據(jù)模型是什么？

采用znode（節(jié)點樹）來保存數(shù)據(jù)，znode內(nèi)部可以保存數(shù)據(jù)，還可以掛載0至多個znode；

每一個節(jié)點都有唯一性，可以用來做統(tǒng)一的命名服務(wù)，其數(shù)據(jù)保存在內(nèi)存中； Znode可以分為臨時的，持久的，普通的，順序的；

因此，它4種存儲類型：普通臨時，普通持久，順序臨時，順序持久

創(chuàng)建節(jié)點的指令：

• creat /park01
• creat -e /park01
• creat -s /park01
• creat -e -s /park01

臨時節(jié)點客戶端斷開后，節(jié)點刪除；

5.Zookeeper的特點：

順序一致性，原子性，單一視圖，可靠性，偽實時性。

6.分布式環(huán)境下數(shù)據(jù)一致性算法？

2PC算法：

所有的參與者都成功事物才成功，原子性操作。

缺點：同步阻塞，單點故障，鬧裂（一個集群中出現(xiàn)兩個以上leader），太保守。

Paxos算法：

拜占庭將軍問題-> 三支相隔遙遠的軍隊一起打某個國家，分布式環(huán)境下達成協(xié)議， 信使傳遞消息，信使被收買怎么辦？ 信道不可靠解決不了這個問題。

Paxos算法采用過半機制，一半通過則協(xié)議達成，還支持角色替換，但是會產(chǎn)生活鎖的問題，兩個人一直讓不開的問題。

ZAB算法： 在Paxos的基礎(chǔ)上改進，支持崩潰恢復(fù)，就是選舉產(chǎn)生活鎖的時候，集群停止工作，重新選舉。

7.看圖說話

8.Zookeeper的事物操作 ？

事物Zxid全局唯一，遞增，zxid越大，事物越新，在選舉的時候，可以用到。 選舉id: 置文件中配置，事物Zxid選舉不出來，用選舉ID；

9.補充:

心跳機制時間，默認10秒，可以調(diào)整，集群環(huán)境不好，可以調(diào)整 原子廣播端口：2888；選舉端口自己配置：3888； 配置觀察者模式指定觀察者

10.圖解——Zookeeper的選舉 ？

原子廣播：選舉 和 寫入操作時影響性能；

Observe觀察者，服從投票結(jié)果，不參與投票，能提供性能。 例如：阿里Observe的應(yīng)用，杭州leader和flower，每個和青島observer

提供一個教材給大家學(xué)習(xí)
https://www.yiibai.com/zookeeper/zookeeper_api.html