Zookeeper 的通信及會話

1. 前言

在前面的章節中，我們學習了 Zookeeper 的 Java 客戶端 ZkClient 和 Curator 的基本使用，那這些客戶端是如何與 Zookeeper 服務端建立通信的呢？我們就帶著這個問題開啟本節的內容。

2. Zookeeper 的通信協議

首先我們從 Zookeeper 的通信協議開始說起。我們都知道最常用的網絡通信協議 TCP/IP 協議，而 Zookeeper 就是基于 TCP/IP 協議實現了自己的通信方式。

Zookeeper 的通信協議分為兩部分，請求協議和響應協議，接下來我們分別進行介紹。

2.1 請求協議

請求協議是 Zookeeper Client 向 Zookeeper Server 發送請求時所使用的協議，包含了請求頭和請求體。在 Zookeeper 中使用了 RequestHeader 類作為請求頭。

// RequestHeader 類實現了 Record 接口來進行序列化操作
public class RequestHeader implements Record{
    // 客戶端序號，記錄客戶端請求發起的順序
    private int xid;
    // 請求類型
    private int type;
}

而請求體會根據不同的請求類型來進行封裝，接下來我們以會話創建、節點查詢、節點更新三種類型的請求分別介紹相對應的請求體。

• 會話創建請求
  當 Zookeeper 客戶端向 Zookeeper 服務端發送會話創建的請求時，使用 ConnectRequest 類來封裝請求體：

// ConnectRequest 類實現了 Record 接口來進行序列化操作
public class ConnectRequest implements Record {
	// 請求協議的版本信息
    private int protocolVersion;
    // 最后一次接收到響應的服務端 zxid
    private long lastZxidSeen;
    // 會話超時時間
    private int timeOut;
    // 會話 id
    private long sessionId;
    // 密碼
    private byte[] passwd;
}

• 節點查詢請求
  當 Zookeeper 客戶端向 Zookeeper 服務端發送節點查詢的請求時，使用 GetDataRequest 類來封裝請求體：

  // GetDataRequest 類實現了 Record 接口來進行序列化操作
  public class GetDataRequest implements Record {
      // 節點全路徑
      private String path;
      // 是否對該節點開啟監聽
      private boolean watch;
  }
  

• 節點更新請求
  當 Zookeeper 客戶端向 Zookeeper 服務端發送節點更新的請求時，使用 SetDataRequest 類來封裝請求體：

  // SetDataRequest 類實現了 Record 接口來進行序列化操作
  public class SetDataRequest implements Record {
  	// 節點全路徑
      private String path;
      // 節點更新的數據
      private byte[] data;
      // 節點更新后的版本，也就是在當前版本上加 1
      private int version;
  }
  

介紹了 Zookeeper 的請求協議之后，接下來我們繼續學習 Zookeeper 的響應協議。

2.2 響應協議

響應協議會在接收到 Zookeeper 客戶端的請求后，對請求協議進行解析并作出響應。和 Zookeeper 的請求協議相對應的，Zookeeper 的響應協議也是由響應頭和響應體組成，響應體也需要根據不同的請求類型來封裝響應體。在接收到 Zookeeper 客戶端的請求后，由 ReplyHeader 類來解析請求頭并對響應頭進行封裝：

// ReplyHeader 類實現了 Record 接口來進行序列化操作
public class ReplyHeader implements Record {
    // 客戶端序號，記錄客戶端請求發起的順序
    private int xid;
    // 事務id
    private long zxid;
    // 錯誤狀態碼
    private int err;
}

• 會話創建響應
  當 Zookeeper 服務端接收到 Zookeeper 客戶端的會話創建請求時，使用 ConnectResponse 類來封裝響應體：

  // ConnectResponse 類實現了 Record 接口來進行序列化操作
  public class ConnectResponse implements Record {
      // 請求協議的版本信息
      private int protocolVersion;
      // 會話超時時間
      private int timeOut;
      // 會話 id
      private long sessionId;
      // 密碼
      private byte[] passwd;
  }
  

• 節點查詢響應
  當 Zookeeper 服務端接收到 Zookeeper 客戶端的節點查詢請求時，使用 GetDataResponse 類來封裝響應體：

  // GetDataResponse 類實現了 Record 接口來進行序列化操作
  public class GetDataResponse implements Record {
      // 節點的數據
      private byte[] data;
      // 節點的狀態
      private org.apache.zookeeper.data.Stat stat;
  }
  

• 節點更新響應
  當 Zookeeper 服務端接收到 Zookeeper 客戶端的節點更新請求時，使用 SetDataResponse 類來封裝響應體：

  // SetDataResponse 類實現了 Record 接口來進行序列化操作
  public class SetDataResponse implements Record {
      // 節點的狀態
      private org.apache.zookeeper.data.Stat stat;
  }
  

介紹完 Zookeeper 的通信協議后，接下來我們要學習的是 Zookeeper 的會話，包括會話的結構，會話的狀態等。

3. Zookeeper 的會話

Zookeeper 是一個 C/S 架構的服務，也就是 Client — Server 的形式。在我們使用 Zookeeper 時，都是使用 Zookeeper 的客戶端向服務端發送請求，然后由服務端做出響應返回到客戶端。在這個過程中，Zookeeper 的客戶端需要與 Zookeeper 服務端建立連接，建立一個連接就是新建一個會話，那么會話的狀態也就是 Zookeeper 客戶端與 Zookeeper 服務端的連接狀態。
接下來我們從會話的結構開始進行講解：

3.1 Session 的結構

會話 Session 的結構包括會話ID、會話超時時間、會話關閉狀態 3 個屬性：

• SessionID： 會話的唯一標識，由 Zookeeper 自動分配。
• TimeOut： 會話從新建到被關閉的時長，這個時間由 Zookeeper 服務端來管理。
• isClosing： 會話關閉的狀態，如果會話已經被關閉，該會話就不會再被使用了。

3.2 Session 的狀態

在 Zookeeper 的運行過程中，會話 Session 會經歷各種狀態的變化，從 Zookeeper 客戶端與 Zookeeper 服務端開始建立連接到連接被關閉，會話的狀態會經歷以下幾種：

• CONNECTING：正在連接狀態，Zookeeper 客戶端與 Zookeeper 服務端建立連接時的狀態；
• CONNECTIED：已連接狀態，Zookeeper 客戶端與 Zookeeper 服務端完成連接的狀態；
• RECONNECTING：正在重新連接狀態，當 Zookeeper 客戶端與 Zookeeper 服務端斷開連接，Session 重連策略發起重新連接時的狀態；
• RECONNECTED：已經重新連接狀態，在 RECONNECTING 的基礎上，完成了 Zookeeper 客戶端與 Zookeeper 服務端的重新連接；
• CLOSE：連接關閉狀態，Zookeeper 客戶端與 Zookeeper 服務端斷開連接的狀態。

4. 總結

在本節內容中，我們學習了 Zookeeper 的通信協議的實現方式，以及 Zookeeper 會話 Session 的結構和運行中的狀態變化。以下是本節內容的總結：

1. Zookeeper 的通信協議。
2. Zookeeper 的會話。