怎樣進行Zookeeper原理解析，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

專注于為中小企業(yè)提供做網(wǎng)站、成都網(wǎng)站建設服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)濟寧免費做網(wǎng)站提供優(yōu)質的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了成百上千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉變。

1. zookeeper角色

• 領導者：負責發(fā)起投票與系統(tǒng)狀態(tài)更新，完成集群寫操作與數(shù)據(jù)同步

• 跟隨者：參與投票選舉，負責將寫請求轉發(fā)給領導者，并接收客戶端請求，相應客戶端查詢

• 觀察者：不參與選舉，轉發(fā)寫請求給leader，接收客戶端請求，提升集群讀取與相應速度（可忽略）

1. Zookeeper核心

• ZAB（Zookeeper Actomic BoardCost）協(xié)議：有兩種模式（恢復模式與廣播模式）

整個zookeeper集群中只有一個節(jié)點即Leader將客戶端的寫操作轉化為事物(或提議proposal)。Leader節(jié)點再數(shù)據(jù)寫完之后，將向所有的follower節(jié)點發(fā)送數(shù)據(jù)廣播請求(或數(shù)據(jù)復制)，等待所有的follower節(jié)點反饋。在ZAB協(xié)議中，只要超過半數(shù)follower節(jié)點反饋OK，Leader節(jié)點就會向所有的follower服務器發(fā)送commit消息。即將leader節(jié)點上的數(shù)據(jù)同步到follower節(jié)點之上

• 原理：

1. ZAB協(xié)議要求每個leader都要經歷三個階段，即發(fā)現(xiàn)，同步，廣播。

2. 發(fā)現(xiàn)：即要求zookeeper集群必須選擇出一個leader進程，同時leader會維護一個follower可用列表。將來客戶端可以這follower中的節(jié)點進行通信。

3. 同步：leader要負責將本身的數(shù)據(jù)與follower完成同步，做到多副本存儲。這樣也是體現(xiàn)了CAP中高可用和分區(qū)容錯。follower將隊列中未處理完的請求消費完成后，寫入本地事物日志中。

4. 廣播：leader可以接受客戶端新的proposal請求，將新的proposal請求廣播給所有的follower。

• 恢復模式（主節(jié)點選舉：啟動和崩潰恢復的情況下）

選舉：

1. Serverid：在配置server時，給定的服務器的標示id。

2. Zxid:服務器在運行時產生的數(shù)據(jù)id，zxid越大，表示數(shù)據(jù)越新。

3. Epoch：選舉的輪數(shù)，即邏輯時鐘。隨著選舉的輪數(shù)++

4. Server狀態(tài)：LOOKING,FOLLOWING,OBSERVING,LEADING

步驟：

1.Server剛啟動（宕機恢復或者剛啟動）準備加入集群，此時讀取自身的zxid等信息。

2.所有Server加入集群時都會推薦自己為leader，然后將（leader id 、 zixd 、 epoch）作為廣播信息，廣播到集群中所有的服務器(Server)。然后等待集群中的服務器返回信息。

3. 收到集群中其他服務器返回的信息，此時要分為兩類：該服務器處于looking狀態(tài)，或者其他狀態(tài)。

（1）  服務器處于looking狀態(tài)

首先判斷邏輯時鐘 Epoch:

a) 如果接收到Epoch大于自己目前的邏輯時鐘（說明自己所保存的邏輯時鐘落伍了）。更新本機邏輯時鐘Epoch，同時 Clear其他服務發(fā)送來的選舉數(shù)據(jù)（這些數(shù)據(jù)已經OUT了）。然后判斷是否需要更新當前自己的選舉情況（一開始選擇的leader id 是自己）

判斷規(guī)則rules judging：保存的zxid最大值和leader Serverid來進行判斷的。先看數(shù)據(jù)zxid,數(shù)據(jù)zxid大者勝出;其次再判斷l(xiāng)eaderServerid, leader Serverid大者勝出；然后再將自身最新的選舉結果(也就是上面提到的三種數(shù)據(jù)（leader Serverid，Zxid，Epoch）廣播給其他server)

b) 如果接收到的Epoch小于目前的邏輯時鐘。說明對方處于一個比較OUT的選舉輪數(shù)，這時只需要將自己的 （leader Serverid，Zxid，Epoch）發(fā)送給他即可。

c) 如果接收到的Epoch等于目前的邏輯時鐘。再根據(jù)a)中的判斷規(guī)則，將自身的最新選舉結果廣播給其他 server。

同時Server還要處理2種情況：

a)如果Server接收到了其他所有服務器的選舉信息，那么則根據(jù)這些選舉信息確定自己的狀態(tài)（Following,Leading），結束Looking，退出選舉。

b)   即使沒有收到所有服務器的選舉信息，也可以判斷一下根據(jù)以上過程之后最新的選舉leader是不是得到了超過半數(shù)以上服務器的支持，如果是則嘗試接受最新數(shù)據(jù)，倘若沒有最新的數(shù)據(jù)到來，說明大家都已經默認了這個結果,同樣也設置角色退出選舉過程。

（2）  服務器處于其他狀態(tài)（Following, Leading）

a)如果邏輯時鐘Epoch相同,將該數(shù)據(jù)保存到recvset,如果所接收服務器宣稱自己是leader,那么將判斷是不是有半數(shù)以上的服務器選舉它,如果是則設置選舉狀態(tài)退出選舉過程

b)否則這是一條與當前邏輯時鐘不符合的消息，那么說明在另一個選舉過程中已經有了選舉結果，于是將該選舉結果加入到outofelection集合中，再根據(jù)outofelection來判斷是否可以結束選舉,如果可以也是保存邏輯時鐘，設置選舉狀態(tài)，退出選舉過程。

崩潰恢復：

新選舉出來的leader不能包含未提交的proposal，即新選舉的leader必須都是已經提交了的proposal的follower服務器節(jié)點。同時，新選舉的leader節(jié)點中含有最高的ZXID。

• 廣播模式（數(shù)據(jù)同步-類兩階段提交（2pc）,但是半數(shù)相應即可）

數(shù)據(jù)一致性：zookeeper采用ZAB協(xié)議的核心就是只要有一臺服務器提交了proposal，就要確保所有的服務器最終都能正確提交proposal。這也是CAP/BASE最終實現(xiàn)一致性的一個體現(xiàn)。

性能：leader服務器與每個follower之間都有一個單獨的隊列進行收發(fā)消息，使用隊列消息可以做到異步解耦。leader和follower之間只要往隊列中發(fā)送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。

Proposal與ZXID：ZXID是一個長度64位的數(shù)字，其中低32位是按照數(shù)字遞增，即每次客戶端發(fā)起一個proposal,低32位的數(shù)字簡單加1。高32位是leader周期的epoch編號，至于這個編號如何產生(我也沒有搞明白)，每當選舉出一個新的leader時，新的leader就從本地事物日志中取出ZXID,然后解析出高32位的epoch編號，進行加1，再將低32位的全部設置為0。這樣就保證了每次新選舉的leader后，保證了ZXID的唯一性而且是保證遞增的。

具體步驟如下：

1. 客戶端發(fā)起一個寫操作請求

2. Leader服務器將客戶端的request請求轉化為事物proposql提案，同時為每個proposal分配一個全局唯一的ID，即ZXID。

3. leader服務器與每個follower之間都有一個隊列，leader將消息發(fā)送到該隊列

4. follower機器從隊列中取出消息處理完(寫入本地事物日志中)畢后，向leader服務器發(fā)送ACK確認。

5. leader服務器收到半數(shù)以上的follower的ACK后，即認為可以發(fā)送commit

6. leader向所有的follower服務器發(fā)送commit消息。

關于怎樣進行Zookeeper原理解析問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關知識。