ZooKeeper 集群的數據同步

1. 前言

在 Zookeeper 的集群模式一節中，我們學習過了 Zookeeper 的每個 Follower 節點都可以對外提供服務，而且為了保證整個 Zookeeper 集群的數據一致，Zookeeper 集群的服務之間還會進行數據同步。那么這個數據同步的過程是如何實現的呢？接下來我們就對 Zookeeper 集群的數據同步機制進行詳細的講解。

2. ZAB 的消息廣播模式

Zookeeper 為了保證 Zookeeper 集群的數據一致性，使用了 ZAB 協議，在正常工作模式下，ZAB 協議會使用消息廣播模式來讓 Leader 來對事務性消息進行廣播，而且只能有一個 Leader 進行廣播。接下來我們就來講解這個消息廣播模式是如何工作的。

2.1 消息廣播的數據同步

在我們使用 Zookeeper 客戶端向 Zookeeper 集群的某一個 Follower 發送事務請求時，也就是對 Znode 節點的增刪改操作時，這個Follower 節點并不會自己去處理這個事務請求，而是會把這個請求轉發給 Leader 節點，讓 Leader 節點來處理事務請求。

Leader 節點接收到 Follower 轉發過來的請求，會生成與事務請求相對應的 Proposal 事務提案，并為這個 Proposal 事務提案分配全局唯一的單調遞增的事務ID，也就是 ZXID，然后把 Proposal 事務提案發送到集群中所有的 Follower 節點。

如果 Leader 節點接收到了多個 Follower 節點轉發的請求，Leader 節點會根據 Proposal 事務提案的 ZXID 的先后順序來對 Follower 節點進行廣播。

Follower 節點接收到 Proposal 事務提案后，會把接收到的 Proposal 事務提案以事務日志的方式寫入本地磁盤中，成功后會向 Leader 節點返回 Ack 確認信息，確定自己能夠執行該事務。在這一步驟中， Follower 向 Leader 發送反饋，確認 Follower 節點能夠執行該事務，但不會去提交該事務請求。

Leader 節點接收到半數以上的 Follower 節點返回的 Ack 確認信息后，就會向所有的 Follower 節點廣播 Commit 消息，通知 Follower 節點提交事務請求，同時 Leader 節點自己也會提交該事務請求。接收到 Commit 消息的 Follower 節點就會開始進行事務提交。

當 Follower 節點完成事務的提交后，Leader 節點就會把該 Follower 節點加入可用的 Follower 列表中，該Follower 節點就可以對外提供服務了。

除了 Follow 節點需要進行數據同步外，Zookeeper 集群還有一種叫做 Observer 的節點會進行數據同步，那么我們接下來簡單介紹一下 Observer 節點。

3. Observer

Observer 節點是 Zookeeper 3.3.0 版本新增的 Zookeeper 集群的角色，Observer 作為觀察者在 Zookeeper 集群中觀察 Zookeeper 集群的最新的數據變化，然后從 Leader 節點獲取最新變化的數據并同步到自身，然后再向外提供服務。

Observer 節點可以獨立的處理 Zookeeper 客戶端的非事務請求，也就是查詢請求。如果接收到 Zookeeper 客戶端的事務請求，Observer 節點會把請求轉發給 Leader 節點，但不會接收到 Leader 節點的 Proposal 事務提案，避免影響 Zookeeper 集群處理事務請求的效率。這是 Observer 節點與 Follower 節點的區別之一。

Observer 節點與 Follower 節點的區別之二，Observer 節點不會參與 Zookeeper 集群的 Leader 選舉，避免太多候選者而降低 Zookeeper 集群選舉 Leader 的效率。

簡單的介紹了 Observer 節點是什么，以及 Observer 節點和 Follower 節點的區別，接下來我們講解 Observer 節點是如何實現與 Leader 節點進行數據同步的。

3.1 Observer 的數據同步

增加 Observer 節點的主要作用是用來提高 Zookeeper 集群的非事務請求的效率，我們可以在 zoo.cfg 配置文件中添加如下配置：

# 聲明此服務為 Observer 節點
peerType=observer

在 zoo.cfg 中配置 Zookeeper 服務列表時需要添加 observer 標識：

# 添加 observer 標識，聲明 server.1 為 Observer 節點
server.1:192.168.0.77:2181:3181:observer

我們啟動 Zookeeper 服務時，會加載配置文件的 peerType 屬性來識別該服務是否為 Observer 節點，如果是 Observer 節點，就會使用 ObserverZooKeeperServer 類來實例化該 Observer 節點。

由于 Observer 節點不接收 Leader 節點廣播的 Proposal 事務提案，也就不能在這一步獲取 Proposal 事務提案中的事務請求，那么 Observer 節點如何獲得事務請求的信息呢？答案是 Observer 節點會從 INFORM 消息中獲取已提交的事務信息。

INFORM 消息是 Leader 節點在自身的事務提交成功后向 Observer 節點發出的消息，通知 Observer 更新數據。Observer 接收到 Leader 節點發出的 INFORM 消息后，從 INFORM 消息中獲取 Leader 節點已經提交的事務，就可以對自身的數據進行更新了，而且不需要向Leader 節點發送反饋信息。

4. 總結

在本節內容中，我們學習了 Zookeeper ZAB 協議的消息廣播模式，以及在消息廣播模式中 Zookeeper 集群的各個節點的數據同步過程，還有 Observer 節點的特點以及 Observer 節點的數據同步。以下是本節內容總結：

1. Zookeeper ZAB 協議的消息廣播模式。
2. 消息廣播模式下的數據同步過程。
3. Observer 節點的特點。
4. Observer 節點與 Leader 節點的數據同步。