怎樣進行Zookeeper原理解析

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

1. zookeeper角色

• 領導者：負責發起投票與系統狀態更新，完成集群寫操作與數據同步

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

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

1. Zookeeper核心

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

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

• 原理：

1. ZAB協議要求每個leader都要經歷三個階段，即發現，同步，廣播。

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

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

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

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

選舉：

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

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

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

4. Server狀態：LOOKING,FOLLOWING,OBSERVING,LEADING

步驟：

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

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

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

（1）  服務器處于looking狀態

首先判斷邏輯時鐘 Epoch:

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

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

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

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

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

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

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

（2）  服務器處于其他狀態（Following, Leading）

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

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

崩潰恢復：

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

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

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

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

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

具體步驟如下：

1. 客戶端發起一個寫操作請求

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

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

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

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

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

關于怎樣進行Zookeeper原理解析問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。