Zookeeper Cluster

Zookeeper 集群原理

集群节点角色

一个 ZooKeeper 集群通常由奇数台服务器组成（如 3、5、7 台），每个节点称为一个 Server，在运行过程中会扮演以下角色之一：

• Leader

  • 负责处理所有写请求
  • 发起事务提议（Proposal）
  • 协调数据同步与提交

• Follower

  • 参与 Leader 选举
  • 接收并处理客户端的读请求
  • 参与事务投票（ACK）

• Observer（可选）

  • 不参与投票
  • 仅用于分担读请求压力
  • 提高读扩展能力而不影响写一致性

生产环境中最常见的是 Leader + Follower 架构。

Leader 选举机制

Leader 选举发生在以下场景：

• 集群首次启动
• Leader 宕机
• 网络分区导致 Leader 不可用

选举原则：

• 以 ZXID（事务 ID）最大者优先
• 若 ZXID 相同，则 Server ID 大者胜出
• 必须获得超过半数节点的投票

ZXID 越大，说明数据越新。

一致性保证（ZAB 协议）

ZooKeeper 采用 ZAB（ZooKeeper Atomic Broadcast）协议，保证以下特性：

• 顺序一致性：所有事务按全局顺序执行
• 原子性：事务要么成功，要么失败
• 单一系统映像：所有客户端看到的数据视图一致

写流程简化如下：

1. 客户端将写请求发送给 Leader
2. Leader 生成事务 Proposal
3. Follower 接收 Proposal 并返回 ACK
4. 超过半数节点 ACK 后，Leader 提交事务
5. 所有节点应用该事务

读写特性与性能模型

• 读请求

  • 可由任意 Leader / Follower / Observer 处理
  • 延迟低，吞吐高

• 写请求

  • 只能由 Leader 处理
  • 性能受限于网络与磁盘同步

因此，ZooKeeper 适合：

• 读多写少
• 小数据、高一致性的场景

不适合：

• 大数据存储
• 高并发写入

Zookeeper 集群搭建

在每个 Zookeeper 实例：

1. data 目录下创建一个 myid 文件，内容分别为 1、2、3，该数值将作为 Zookeeper 的实例 ID；

2. zoo.cfg 文件中配置：

   • 客户端访问端口（可选，在同一个服务器上运行多个 Zookeeper 实例时需要）

     clientPort=2181

   • 集群服务器 IP 列表

     server.1=SERVER1:2888:3888
     server.2=SERVER2:2888:3888
     server.3=SERVER3:2888:3888

     配置格式为 server.<id>=<host>:<follower_port>:<election_port>，各配置项说明：

     • id：必须与该节点 data 目录下的 myid 文件内容一致
     • host：该服务器的主机名或 IP 地址
     • follower_port：Follower 端口。Follower 节点使用此端口连接到 Leader 节点，进行数据同步和心跳通信
     • election_port：Leader 选举端口。用于 Leader 选举过程