Zookeeper核心原理

Zookeeper 的核心原理

Zookeeper 的由來

1. 各個節點的數據一致性

2. 怎麼保證任務只在一個節點執行

3. 若是orderserver1掛了，其餘節點如何發現並接替

4. 存在共享資源，互斥性、安全性

 

Apache 的Zookeeper

Google 的Chubby 是一個分佈式鎖服務，經過Google Chubby 來解決分佈式協做、Master選舉等與分佈式鎖服務相關的問題

 

Zookeeper 的設計猜測

1. 防止單點故障

   1. 集羣方案（Leader Follower）還能分擔請求，既作了高可用，又作高性能

2. 每一個節點的數據是一致的（必需要有leader）

   leader master（帶中心化的） redis-cluser （無中心化的）

3. 集羣中的leader 掛了，怎麼辦？數據怎麼恢復？

   選舉機制？數據恢復

4. 如何去保證數據一致性？(分佈式事務)

   2PC 協議、二階提交

2PC

（Two Phase Commitment Protocol）當一個事務操做須要跨越多個分佈式節點的時候，爲了保持事務處理的ACID特性，就須要引入一個「協調者」（TM）來統一調度全部分佈式節點的執行邏輯，這些被調度的分佈式節點被稱爲AP。TM 負責調度AP 的行爲，並最終決定這些AP是否要把事務真正進行提交；由於整個事務分爲兩個階段提交，因此叫2PC.

階段一：提交事務請求

1. 事務詢問

   1. 協調者向全部的參與者發送事務內容，詢問是否能夠執行事務提交操做，並開始等待各參與者的響應。

2. 執行事務

   1. 各個參與者節點執行事務操做，並將Undo和Redo信息記錄到事務日誌中，儘可能把提交過程當中全部消耗時間的操做和準備的提早完成確保後面100%成功提交事務

3. 各個參與者向協調者反饋事務詢問的響應

   1. 若是各個參與者都成功執行了事務操做，那麼就反饋給參與者yes的響應，表示事務能夠執行；

   2. 若是參與者沒有成功執行事務，就反饋給協調者no的響應，表示事務不能夠執行；

   3. 2pc 協議的第一個階段稱爲「投票階段」，即各參與者投票表名是否須要繼續執行接下去的事務提交操做。

階段二：執行事務提交

在這個階段，協調者會根據各參與者的反饋狀況來決定最終是否能夠進行事務提交操做；

兩種可能：

• 執行事務

• 中斷事務

 

Zookeeper 的集羣角色

在zookeeper中，客戶端隨機鏈接到zookeeper中的一個節點。

若是是讀請求，就直接從當前節點中讀取數據

 

若是是寫請求，那麼請求會轉發給leader 提交事務，而後leader將事務廣播給集羣中的follower節點（注意obeserver節點不參與投票），Follower 節點給leader 一個ack (ack表示當前的節點是否是能執行這個事務)，只要有超過半數節點寫入成功，那麼寫請求就會被提交。集羣節點須要（2n+1）

Leader 角色

是zookeeper中的整個核心，起到了主導整個集羣的做用

1. 事務請求的調度和處理

2. 保證事務處理的順序性

Follower角色

1. 處理客戶端的非事務請求，

2. 轉發事務請求給leader服務器

3. 參與事務請求Proposal 的投票（須要半數以上服務器經過才能通知leader commit數據; Leader發起的提案， 要求Follower投票）

4. 參與leader節點選舉的投票

Observer角色

是一個觀察者角色

1. 瞭解集羣中的狀態變化 ，和對這些狀態進行同步

2. 工做原理和follower節點同樣，惟一差異是不參與事務請求的投票，不參與Leader選舉

3. Observer 只提供非事務請求，一般在於不影響集羣事務處理能力的前提下，提高集羣非事務處理能力

注：

爲何須要2n+1節點

表示奇數節點， zookeeper中要正常對外提供服務的話，它裏面有個投票機制，這個機制就是必需要有過半的機器正常工做，而且可以彼此完成通訊進行事務投票結果。

ZAB協議

ZAB（Zookeeper Atomic Broadcast） 協議是爲分佈式協調服務。ZooKeeper 專門設計的一種支持崩潰恢復的原子 廣播協議。在 ZooKeeper 中，主要依賴 ZAB 協議來實現分佈式數據一致性，基於該協議，ZooKeeper 實現了一種主備模式的系統架構來保持集羣中各個副本之間的數據一致性。

ZAB

支持崩潰恢復的原子廣播協議，主要用於數據一致性

ZAB協議基本模式

• 崩潰恢復（恢復leader節點和恢復數據）

• 原子廣播

消息廣播的實現原理

消息廣播過程實際是一個簡化版的二階提交。2PC

1. leader 接收到消息請求後，將消息賦予一個全局惟一的64位自增id（ZXID）。ZXID大小，實現因果有序的特徵。

2. leader 爲每個follower 準備了一個FIFO隊列，將帶有zxid的消息做爲一個提案（Proposal）分發給全部follower

3. 當follower 收到proposal，先把proposal寫到磁盤，寫入成功後，再向leader 回覆一個ack

4. 當leader接收到合法數量的ack後，leader 就會向這個follower 發送commit命令，同時會在本地執行該消息。

5. 當follower 收到消息的commit之後，會提交該消息。

注：leader 的投票過程，不須要Observer 的ack,可是Observer必需要同步Leader的數據，保證數據的一致性。

崩潰恢復

1. 當leader失去了過半的follower節點的聯繫

2. 當leader服務器宕機

集羣進去崩潰恢復階段

對於數據恢復來講

1. 已經處理的消息不能丟失

   1. 當leader 收到合法數量的follower 的ack之後，就會向各個follower 廣播消息（commit命令），同時本身也會commit 這條事務消息。

   2. 若是follower節點收到commit命令以前，leader掛了，會致使部分節點收到commit,部分節點沒有收到。

   3. ZAB協議須要保證已經處理的消息不能丟失。

2. 被丟棄的消息不能再次出現

3. 當Leader收到事務請求，還未發起事務投票以前，leader掛了

ZAB 協議須要知足以上兩種狀況，必須要設計一個leader選舉算法：可以保證已經被leader提交的事務Proposal可以提交、同時丟棄已經被跳過的事務Proposal。

ZAB的設計思想

1. zxid 是最大的

   1. 若是leader選舉算法可以保證新選舉出來的leader服務器擁有集羣中全部機器最高編號（ZXID最大）的事務Proposal,那麼就能夠保證這個新選舉出來的Leader必定具備已經提交的提案。由於全部提案被Commit以前必須有超過半數的Follower ACK,即必須有超過半數的服務器的事務日誌上有該提案的proposal,所以，只要有合法數量的節點正常工做，就必然有一個節點保存了全部被commit消息的proposal狀態。

2. epoch的概念，每產生一個新的leader,那麼新的leader的epoch會+1,zxid 是64位的數據，低32位表示消息計數器（自增），每收到一條消息，這個值+1，新 leader選舉後這個值重置爲0。這樣設計的緣由在於，老的leader 掛了之後重啓，他不會選舉爲leader,y所以此時它的zxid確定小於當前新的leader.當老的 leader 做爲 follower 接入新的 leader 後，新的 leader會讓它將全部的擁有舊的epoch號的未被COMMIT的proposal清除 .高32位會存儲epoch編號

ZXID

ZXID ，事務ID

爲了保證事務順序的一致性，Zookeeper 採用了遞增的事務id號來標識事務。

全部的提議Proposal都在被提出的時候加上了zxid.

ZXID 是一個64位的數字（低32位和高32位組成）

• 低32位：表示消息計數器

• 高32位 ：表示epoch，用來標識 leader 關係是否改變。 每次一個leader被選出來，都會有一個新的epoch(原來的epoch+1),標識當前屬於那個leader的統治時期。

注：

epoch: 能夠理解爲當前集羣所處的年代或者週期。

leader: 相似，有本身的年號，每次變動都會在前一個年代上加1。

Linux下查看epoch

/tmp/zookeeper/VERSION-2 路徑會看到一個 currentEpoch文件。文件顯示的是當前的epoch

經過命令查看事務日誌

java -cp :/opt/zookeeper/zookeeper-3.4.10/lib/slf4j-api-1.6.1.jar:/opt/zookeeper/zookeeper-3.4.10/zookeeper-3.4.10.jar org.apache.zookeeper.server.LogFormatter /tmp/zookeeper/version-2/log.100000001

Leader 選舉

注：

Fast Leader

ZXID（事務ID）事務ID 越大，那麼表示數據越新， 最大會設置爲Leader， ,

epoch ，每一輪投票，epoch 都會遞增

myid (服務器id ,server id)

myid 越大，在leader 選舉機制中權重越大

服務啓動時的狀態都是LOOKING，觀望狀態

LEADING

FOLLOWING

OBSERVING

服務器啓動時的Leader 選舉

1. 每一個服務器發出一個投票，初始狀況，都會將本身做爲Leader服務器進行投票，而後發送給其餘集羣中的服務器。

   1. 投票信息包含（myid,zxid,epoch）

2. 接受來自各個服務器的投票

   1. 判斷該投票是否有效

      1. 檢查是否來自本輪投票epoch

      2. 檢查是否來時LOOKING狀態的服務器

3. 處理投票

   1. 檢查ZXID，若是ZXID比較大，那麼設置爲Leader,

   2. 若是ZXID相同，會檢查myid,myid比較大的，設置爲leader

4. 統計投票

   1. 判斷是否已經有過半機器接受到相同的投票信息

   2. 若是有過半機器接受，便認爲已經選舉出了Leader

5. 改變服務器狀態

1. 若是是Follower,那麼狀態變爲FOLLOWING

2. 若是是Leader，那麼狀態變爲LEADING

Leader 崩潰時的Leader選舉

1. 變動狀態

   1. Leader 掛後，餘下非Observer服務器都會將本身的服務器狀態變爲LOOKING,

   2. 開始進入Leader選舉過程

2. 每一個Server會發起一個投票。

   1. 運行期間，ZXID 可能不一樣，而後將各自的投票發送給集羣中的全部機器。

3. 其他與啓動時過程相同。