ZooKeeper集羣解析

ZooKeeper集羣解析。sql

這篇文章中來介紹一下 ZooKeeper 相關的集羣角色，還有 ZAB協議，集羣的安裝在 ZooKeeper入門中有介紹。服務器

1、ZooKeeper集羣中的角色

Leader 集羣工做機制中的核心事務請求的惟一調度和處理者，保證集羣事務處理的順序集羣內部個服務器的調度者(管理 follower,數據同步)，爲客戶端提供讀和寫的服務，負責投票的發起和決議，更新系統狀態。
Follower 集羣工做機制中的跟隨者處理非事務請求，爲客戶端提供讀服務，若是是寫服務則轉發給Leader，參與事務請求 proposal 投票參與 leader 選舉投票。
Observer 觀察者3.30 以上版本提供，和 follower 功能相同，但不參與任何形式投票處理非事務請求，轉發事務請求給 Leader 提升集羣非事務處理能力，若是版本高於3.30須要配置使用方式:server.0=192.168.182.130:2888:3888:Observer。

2、ZooKeeper集羣一致性協議ZAB

ZAB協議的實現借鑑於 Paxos，是爲了解決分佈式系統的數據一致性問題。markdown

1. 總覽

zookeeper 就是根據 zab 協議創建了主備模型完成集羣的數據同步（保證數據的一致性），前面介紹了集羣的各類角色，這說所說的主備架構模型指的是，在 zookeeper 集羣中，只有一臺 leader（主節點）負責處理外部客戶端的事務請求（寫操做），leader 節點負責將客戶端的寫操做數據同步到全部的 follower 節點中，大概流程以下：網絡

zab 協議核心是在整個 zookeeper 集羣中只有一個節點既 leader 將全部客戶端的寫操做轉化爲事務（提議 proposal），leader 節點再數據寫完以後，將向全部的 follower 節點發送數據廣播請求（數據複製）。
等全部的 follower 節點的反饋。
在 zab 協議中，只要超過半數 follower 節點反饋 ok，leader 節點會向全部 follower 服務器發送 commit 消息，既將 leader 節點上的數據同步到 follower 節點之上。

2. 崩潰恢復

何時會發生崩潰恢復？

當服務器啓動時
當leader 服務器出現網絡中斷，崩潰或者重啓的狀況
當集羣中已經不存在過半的服務器與Leader服務器保持正常通訊

崩潰恢復的過程

每一個 Server 會發出一個投票,第一次都是投本身。投票信息：（myid，ZXID）
收集來自各個服務器的投票
處理投票並從新投票，處理邏輯：優先比較 ZXID,而後比較 myid
統計投票，只要超過半數的機器接收到一樣的投票信息，就能夠肯定 leader
改變服務器狀態

爲何要有限比較ZXID呢？架構

由於ZXID爲事務id，值越大，證實它的數據最新。分佈式

在這個選舉過程當中每一個 Server 有三種狀態：oop

LOOKING：當前Server不知道leader是誰，正在搜尋
LEADING：當前Server即爲選舉出來的leader
FOLLOWING：leader已經選舉出來，當前Server與之同步

兩種特殊狀況

已經被處理的事務請求（proposal）不能丟（commit的）。
沒被處理的事務請求（proposal）不能再次出現。

狀況一的出現場景：post

當 leader 收到合法數量 follower 的 ACK 後，就向各個 follower 廣播 commit 命令，同時也會在本地執行 commit 並向鏈接的客戶端返回成功，可是若是在各個 follower 在收到 commit 命令前 leader 就掛了，致使剩下的服務器並無執行都這條消息。spa

那麼這種狀況要怎麼處理呢？日誌

一、選舉 ZXID 最大的節點做爲新的 leader：因爲全部提案被 commit 以前必須有合法數量的 follower ACK，即必須有合法數量的服務器的事務日誌上有該 proposal，所以，ZXID 最大也就是數據最新的節點保存了全部被 commit 消息的 proposal 狀態。二、新的 leader 將本身事務日誌中 proposal 但未 COMMIT 的消息處理。三、新的 leader 與 follower 創建先進先出的隊列，先將自身有而 follower 沒有的 proposal 發送給 follower，再將這些 proposal 的 COMMIT 命令發送給 follower，以保證全部的 follower 都保存了全部的 proposal、全部的 follower 都處理了全部的消息，經過以上策略，能保證已經被處理的消息不會丟。

狀況二的出現場景

當 leader 接收到消息請求生成 proposal 後就掛了，其餘 follower 並無收到此 proposal，所以通過恢復模式從新選了 leader 後，這條消息是被跳過的，此時，以前掛了的 leader 從新啓動並註冊成了 follower，他保留了被跳過消息的 proposal 狀態，與整個系統的狀態是不一致的，因此須要將其刪除。

3. 消息廣播

在 zookeeper 集羣中數據副本的傳遞策略就是採用的廣播模式，Zab 協議中的 leader 等待 follower 的 ack 反饋，只要半數以上的 follower 成功反饋就好，不須要收到所有的 follower 反饋。

具體步驟以下：

客戶端發起一個寫操做請求
Leader 服務器將客戶端的 request 請求轉化爲事物 proposql 提案，同時爲每一個 proposal 分配一個全局惟一的 ID，即 ZXID
leader 服務器與每一個 follower 之間都有一個隊列，leader 將消息發送到該隊列
follower 機器從隊列中取出消息處理完(寫入本地事物日誌中)畢後，向 leader 服務器發送 ACK 確認
leader 服務器收到半數以上的 follower 的 ACK 後，即認爲能夠發送 commit
leader 向全部的 follower 服務器發送 commit 消息

都讀到這裏了，來個 點贊、評論、關注、收藏 吧！

文章做者：IT王小二
首發地址：www.itwxe.com/posts/2c8e1…
版權聲明：文章內容遵循署名-非商業性使用-禁止演繹 4.0 國際進行許可，轉載請在文章頁面明顯位置給出做者與原文連接。