談?wù)勀銓?duì)Zookeeper的理解？

Zookeeper是一個(gè)開源的分布式協(xié)調(diào)服務(wù)，由雅虎公司創(chuàng)建，由于最初雅虎公司的內(nèi)部研究小組的項(xiàng)目大多以動(dòng)物的名字命名，所以后來就以Zookeeper(動(dòng)物管理員)來命名了，而就是由Zookeeper來負(fù)責(zé)這些分布式組件環(huán)境的協(xié)調(diào)工作。

他的目標(biāo)是可以提供高性能、高可用和順序訪問控制的能力，同時(shí)也是為了解決分布式環(huán)境下數(shù)據(jù)一致性的問題。

集群

首先，Zookeeper集群中有幾個(gè)關(guān)鍵的概念，Leader、Follower和Observer，Zookeeper中通常只有Leader節(jié)點(diǎn)可以寫入，F(xiàn)ollower和Observer都只是負(fù)責(zé)讀，但是Follower會(huì)參與節(jié)點(diǎn)的選舉和過半寫成功，Observer則不會(huì)，他只是單純的提供讀取數(shù)據(jù)的功能。

通常這樣設(shè)置的話，是為了避免太多的從節(jié)點(diǎn)參與過半寫的過程，導(dǎo)致影響性能，這樣Zookeeper只要使用一個(gè)幾臺(tái)機(jī)器的小集群就可以實(shí)現(xiàn)高性能了，如果要橫向擴(kuò)展的話，只需要增加Observer節(jié)點(diǎn)即可。

Zookeeper建議集群節(jié)點(diǎn)個(gè)數(shù)為奇數(shù)，只要超過一半的機(jī)器能夠正常提供服務(wù)，那么整個(gè)集群都是可用的狀態(tài)。

數(shù)據(jù)節(jié)點(diǎn)Znode

Zookeeper中數(shù)據(jù)存儲(chǔ)于內(nèi)存之中，這個(gè)數(shù)據(jù)節(jié)點(diǎn)就叫做Znode，他是一個(gè)樹形結(jié)構(gòu)，比如/a/b/c類似。

而Znode又分為持久節(jié)點(diǎn)、臨時(shí)節(jié)點(diǎn)、順序節(jié)點(diǎn)三大類。

持久節(jié)點(diǎn)是指只要被創(chuàng)建，除非主動(dòng)移除，否則都應(yīng)該一直保存在Zookeeper中。

臨時(shí)節(jié)點(diǎn)不同的是，他的生命周期和客戶端Session會(huì)話一樣，會(huì)話失效，那么臨時(shí)節(jié)點(diǎn)就會(huì)被移除。

還有就是臨時(shí)順序節(jié)點(diǎn)和持久順序節(jié)點(diǎn)，除了基本的特性之外，子節(jié)點(diǎn)的名稱還具有有序性。

會(huì)話Session

會(huì)話自然就是指Zookeeper客戶端和服務(wù)端之間的通信，他們使用TCP長(zhǎng)連接的方式保持通信，通常，肯定會(huì)有心跳檢測(cè)的機(jī)制，同時(shí)他可以接受來自服務(wù)器的Watch事件通知。

事件監(jiān)聽器Wather

用戶可以在指定的節(jié)點(diǎn)上注冊(cè)Wather，這樣在事件觸發(fā)的時(shí)候，客戶端就會(huì)收到來自服務(wù)端的通知。

權(quán)限控制ACL

Zookeeper使用ACL來進(jìn)行權(quán)限的控制，包含以下5種：

1. CREATE，創(chuàng)建子節(jié)點(diǎn)權(quán)限
2. DELETE，刪除子節(jié)點(diǎn)權(quán)限
3. READ，獲取節(jié)點(diǎn)數(shù)據(jù)和子節(jié)點(diǎn)列表權(quán)限
4. WRITE，更新節(jié)點(diǎn)權(quán)限
5. ADMIN，設(shè)置節(jié)點(diǎn)ACL權(quán)限

所以，Zookeeper通過集群的方式來做到高可用，通過內(nèi)存數(shù)據(jù)節(jié)點(diǎn)Znode來達(dá)到高性能，但是存儲(chǔ)的數(shù)據(jù)量不能太大，通常適用于讀多寫少的場(chǎng)景。

Zookeeper有哪些應(yīng)用場(chǎng)景？

1. 命名服務(wù)Name Service，依賴Zookeeper可以生成全局唯一的節(jié)點(diǎn)ID，來對(duì)分布式系統(tǒng)中的資源進(jìn)行管理。
2. 分布式協(xié)調(diào)，這是Zookeeper的核心使用了。利用Wather的監(jiān)聽機(jī)制，一個(gè)系統(tǒng)的某個(gè)節(jié)點(diǎn)狀態(tài)發(fā)生改變，另外系統(tǒng)可以得到通知。
3. 集群管理，分布式集群中狀態(tài)的監(jiān)控和管理，使用Zookeeper來存儲(chǔ)。
4. Master選舉，利用Zookeeper節(jié)點(diǎn)的全局唯一性，同時(shí)只有一個(gè)客戶端能夠創(chuàng)建成功的特點(diǎn)，可以作為Master選舉使用，創(chuàng)建成功的則作為Master。
5. 分布式鎖，利用Zookeeper創(chuàng)建臨時(shí)順序節(jié)點(diǎn)的特性。

說說Wather監(jiān)聽機(jī)制和它的原理？

Zookeeper可以提供分布式數(shù)據(jù)的發(fā)布/訂閱功能，依賴的就是Wather監(jiān)聽機(jī)制。

客戶端可以向服務(wù)端注冊(cè)Wather監(jiān)聽，服務(wù)端的指定事件觸發(fā)之后，就會(huì)向客戶端發(fā)送一個(gè)事件通知。

他有幾個(gè)特性：

1. 一次性：一旦一個(gè)Wather觸發(fā)之后，Zookeeper就會(huì)將它從存儲(chǔ)中移除
2. 客戶端串行：客戶端的Wather回調(diào)處理是串行同步的過程，不要因?yàn)橐粋€(gè)Wather的邏輯阻塞整個(gè)客戶端
3. 輕量：Wather通知的單位是WathedEvent，只包含通知狀態(tài)、事件類型和節(jié)點(diǎn)路徑，不包含具體的事件內(nèi)容，具體的時(shí)間內(nèi)容需要客戶端主動(dòng)去重新獲取數(shù)據(jù)

主要流程如下：

1. 客戶端向服務(wù)端注冊(cè)Wather監(jiān)聽
2. 保存Wather對(duì)象到客戶端本地的WatherManager中
3. 服務(wù)端Wather事件觸發(fā)后，客戶端收到服務(wù)端通知，從WatherManager中取出對(duì)應(yīng)Wather對(duì)象執(zhí)行回調(diào)邏輯

Zookeeper是如何保證數(shù)據(jù)一致性的？

Zookeeper通過ZAB原子廣播協(xié)議來實(shí)現(xiàn)數(shù)據(jù)的最終順序一致性，他是一個(gè)類似2PC兩階段提交的過程。

由于Zookeeper只有Leader節(jié)點(diǎn)可以寫入數(shù)據(jù)，如果是其他節(jié)點(diǎn)收到寫入數(shù)據(jù)的請(qǐng)求，則會(huì)將之轉(zhuǎn)發(fā)給Leader節(jié)點(diǎn)。

主要流程如下：

1. Leader收到請(qǐng)求之后，將它轉(zhuǎn)換為一個(gè)proposal提議，并且為每個(gè)提議分配一個(gè)全局唯一遞增的事務(wù)ID：zxid，然后把提議放入到一個(gè)FIFO的隊(duì)列中，按照FIFO的策略發(fā)送給所有的Follower
2. Follower收到提議之后，以事務(wù)日志的形式寫入到本地磁盤中，寫入成功后返回ACK給Leader
3. Leader在收到超過半數(shù)的Follower的ACK之后，即可認(rèn)為數(shù)據(jù)寫入成功，就會(huì)發(fā)送commit命令給Follower告訴他們可以提交proposal了

ZAB包含兩種基本模式，崩潰恢復(fù)和消息廣播。

整個(gè)集群服務(wù)在啟動(dòng)、網(wǎng)絡(luò)中斷或者重啟等異常情況的時(shí)候，首先會(huì)進(jìn)入到崩潰恢復(fù)狀態(tài)，此時(shí)會(huì)通過選舉產(chǎn)生Leader節(jié)點(diǎn)，當(dāng)集群過半的節(jié)點(diǎn)都和Leader狀態(tài)同步之后，ZAB就會(huì)退出恢復(fù)模式。之后，就會(huì)進(jìn)入消息廣播的模式。

那么，Zookeeper如何進(jìn)行Leader選舉的？

Leader的選舉可以分為兩個(gè)方面，同時(shí)選舉主要包含事務(wù)zxid和myid，節(jié)點(diǎn)主要包含LEADING\FOLLOWING\LOOKING3個(gè)狀態(tài)。

1. 服務(wù)啟動(dòng)期間的選舉
2. 服務(wù)運(yùn)行期間的選舉

服務(wù)啟動(dòng)期間的選舉

1. 首先，每個(gè)節(jié)點(diǎn)都會(huì)對(duì)自己進(jìn)行投票，然后把投票信息廣播給集群中的其他節(jié)點(diǎn)
2. 節(jié)點(diǎn)接收到其他節(jié)點(diǎn)的投票信息，然后和自己的投票進(jìn)行比較，首先zxid較大的優(yōu)先，如果zxid相同那么則會(huì)去選擇myid更大者，此時(shí)大家都是LOOKING的狀態(tài)
3. 投票完成之后，開始統(tǒng)計(jì)投票信息，如果集群中過半的機(jī)器都選擇了某個(gè)節(jié)點(diǎn)機(jī)器作為leader，那么選舉結(jié)束
4. 最后，更新各個(gè)節(jié)點(diǎn)的狀態(tài)，leader改為L(zhǎng)EADING狀態(tài)，follower改為FOLLOWING狀態(tài)

服務(wù)運(yùn)行期間的選舉

如果開始選舉出來的leader節(jié)點(diǎn)宕機(jī)了，那么運(yùn)行期間就會(huì)重新進(jìn)行l(wèi)eader的選舉。

1. leader宕機(jī)之后，非observer節(jié)點(diǎn)都會(huì)把自己的狀態(tài)修改為L(zhǎng)OOKING狀態(tài)，然后重新進(jìn)入選舉流程
2. 生成投票信息(myid,zxid)，同樣，第一輪的投票大家都會(huì)把票投給自己，然后把投票信息廣播出去
3. 接下來的流程和上面的選舉是一樣的，都會(huì)優(yōu)先以zxid，然后選擇myid，最后統(tǒng)計(jì)投票信息，修改節(jié)點(diǎn)狀態(tài)，選舉結(jié)束

那選舉之后又是怎樣進(jìn)行數(shù)據(jù)同步的？

那實(shí)際上Zookeeper在選舉之后，F(xiàn)ollower和Observer（統(tǒng)稱為L(zhǎng)earner）就會(huì)去向Leader注冊(cè)，然后就會(huì)開始數(shù)據(jù)同步的過程。

數(shù)據(jù)同步包含3個(gè)主要值和4種形式。

PeerLastZxid：Learner服務(wù)器最后處理的ZXID

minCommittedLog：Leader提議緩存隊(duì)列中最小ZXID

maxCommittedLog：Leader提議緩存隊(duì)列中最大ZXID

直接差異化同步 DIFF同步

如果PeerLastZxid在minCommittedLog和maxCommittedLog之間，那么則說明Learner服務(wù)器還沒有完全同步最新的數(shù)據(jù)。

1. 首先Leader向Learner發(fā)送DIFF指令，代表開始差異化同步，然后把差異數(shù)據(jù)（從PeerLastZxid到maxCommittedLog之間的數(shù)據(jù)）提議proposal發(fā)送給Learner
2. 發(fā)送完成之后發(fā)送一個(gè)NEWLEADER命令給Learner，同時(shí)Learner返回ACK表示已經(jīng)完成了同步
3. 接著等待集群中過半的Learner響應(yīng)了ACK之后，就發(fā)送一個(gè)UPTODATE命令，Learner返回ACK，同步流程結(jié)束

先回滾再差異化同步 TRUNC+DIFF同步

這個(gè)設(shè)置針對(duì)的是一個(gè)異常的場(chǎng)景。

如果Leader剛生成一個(gè)proposal，還沒有來得及發(fā)送出去，此時(shí)Leader宕機(jī)，重新選舉之后作為Follower，但是新的Leader沒有這個(gè)proposal數(shù)據(jù)。

舉個(gè)栗子：

假設(shè)現(xiàn)在的Leader是A，minCommittedLog=1，maxCommittedLog=3，剛好生成的一個(gè)proposal的ZXID=4，然后掛了。

重新選舉出來的Leader是B，B之后又處理了2個(gè)提議，然后minCommittedLog=1，maxCommittedLog=5。

這時(shí)候A的PeerLastZxid=4，在(1,5)之間。

那么這一條只存在于A的提議怎么處理？

A要進(jìn)行事務(wù)回滾，相當(dāng)于拋棄這條數(shù)據(jù)，并且回滾到最接近于PeerLastZxid的事務(wù)，對(duì)于A來說，也就是PeerLastZxid=3。

流程和DIFF一致，只是會(huì)先發(fā)送一個(gè)TRUNC命令，然后再執(zhí)行差異化DIFF同步。

僅回滾同步 TRUNC同步

針對(duì)PeerLastZxid大于maxCommittedLog的場(chǎng)景，流程和上述一致，事務(wù)將會(huì)被回滾到maxCommittedLog的記錄。

這個(gè)其實(shí)就更簡(jiǎn)單了，也就是你可以認(rèn)為TRUNC+DIFF中的例子，新的Leader B沒有處理提議，所以B中minCommittedLog=1，maxCommittedLog=3。

所以A的PeerLastZxid=4就會(huì)大于maxCommittedLog了，也就是A只需要回滾就行了，不需要執(zhí)行差異化同步DIFF了。

全量同步 SNAP同步

適用于兩個(gè)場(chǎng)景：

1. PeerLastZxid小于minCommittedLog
2. Leader服務(wù)器上沒有提議緩存隊(duì)列，并且PeerLastZxid不等于Leader的最大ZXID

這兩種場(chǎng)景下，Leader將會(huì)發(fā)送SNAP命令，把全量的數(shù)據(jù)都發(fā)送給Learner進(jìn)行同步。

有可能會(huì)出現(xiàn)數(shù)據(jù)不一致的問題嗎？

還是會(huì)存在的，我們可以分成3個(gè)場(chǎng)景來描述這個(gè)問題。

查詢不一致

因?yàn)閆ookeeper是過半成功即代表成功，假設(shè)我們有5個(gè)節(jié)點(diǎn)，如果123節(jié)點(diǎn)寫入成功，如果這時(shí)候請(qǐng)求訪問到4或者5節(jié)點(diǎn)，那么有可能讀取不到數(shù)據(jù)，因?yàn)榭赡軘?shù)據(jù)還沒有同步到4、5節(jié)點(diǎn)中，也可以認(rèn)為這算是數(shù)據(jù)不一致的問題。

解決方案可以在讀取前使用sync命令。

leader未發(fā)送proposal宕機(jī)

這也就是數(shù)據(jù)同步說過的問題。

leader剛生成一個(gè)proposal，還沒有來得及發(fā)送出去，此時(shí)leader宕機(jī)，重新選舉之后作為follower，但是新的leader沒有這個(gè)proposal。

這種場(chǎng)景下的日志將會(huì)被丟棄。

leader發(fā)送proposal成功，發(fā)送commit前宕機(jī)

如果發(fā)送proposal成功了，但是在將要發(fā)送commit命令前宕機(jī)了，如果重新進(jìn)行選舉，還是會(huì)選擇zxid最大的節(jié)點(diǎn)作為leader，因此，這個(gè)日志并不會(huì)被丟棄，會(huì)在選舉出leader之后重新同步到其他節(jié)點(diǎn)當(dāng)中。

如果作為注冊(cè)中心，Zookeeper 和Eureka、Consul、Nacos有什么區(qū)別？

最后，你對(duì)于CAP理論怎么理解？

CAP是一個(gè)分布式系統(tǒng)設(shè)計(jì)的定理，他包含3個(gè)部分，并且最多只能同時(shí)滿足其中兩個(gè)。

1. Consistency一致性，因?yàn)樵谝粋€(gè)分布式系統(tǒng)中，數(shù)據(jù)肯定需要在不同的節(jié)點(diǎn)之間進(jìn)行同步，就比如Zookeeper，所以一致性就是指的是數(shù)據(jù)在不同的節(jié)點(diǎn)之間怎樣保證一致性，對(duì)于純理論的C而言，默認(rèn)的規(guī)則是忽略掉延遲的，因?yàn)槿绻紤]延遲的話，因?yàn)閿?shù)據(jù)同步的過程無論如何都會(huì)有延遲的，延遲的過程必然會(huì)帶來數(shù)據(jù)的不一致。
2. Availability可用性，這個(gè)指的是對(duì)于每一個(gè)請(qǐng)求，節(jié)點(diǎn)總是可以在合理的時(shí)間返回合理的響應(yīng)，比如Zookeeper在進(jìn)行數(shù)據(jù)同步時(shí)，無法對(duì)外提供讀寫服務(wù)，不滿足可用性要求。這里常有的一個(gè)例子是說Zookeeper選舉期間無法提供服務(wù)不滿足A，這個(gè)說法并不準(zhǔn)確，因?yàn)镃AP關(guān)注的是數(shù)據(jù)的讀寫，選舉可以認(rèn)為不在考慮范圍之內(nèi)。所以，可以認(rèn)為對(duì)于數(shù)據(jù)的讀寫，無論響應(yīng)超時(shí)還是返回異常都可以認(rèn)為是不滿足A。
3. Partition-tolerance分區(qū)容錯(cuò)性，因?yàn)樵谝粋€(gè)分布式系統(tǒng)當(dāng)中，很有可能由于部分節(jié)點(diǎn)的網(wǎng)絡(luò)問題導(dǎo)致整個(gè)集群之間的網(wǎng)絡(luò)不連通，所以就產(chǎn)生了網(wǎng)絡(luò)分區(qū)，整個(gè)集群的環(huán)境被分隔成不同的的子網(wǎng)，所以，一般說網(wǎng)絡(luò)不可能100%的不產(chǎn)生問題，所以P一定會(huì)存在。

為什么只能同時(shí)滿足CAP中的兩個(gè)呢？

以A\B兩個(gè)節(jié)點(diǎn)同步數(shù)據(jù)舉例，由于P的存在，那么可能AB同步數(shù)據(jù)出現(xiàn)問題。

如果選擇AP，由于A的數(shù)據(jù)未能正確同步到B，所以AB數(shù)據(jù)不一致，無法滿足C。

如果選擇CP，那么B就不能提供服務(wù)，就無法滿足A。

巨人的肩膀：

https://my.oschina.net/yunqi/blog/3040280

《從Paxos到Zookeeper分布式一致性原理與實(shí)踐》