文章目录

- - 一、集群架构：Leader-Follower 模式
  - 二、核心机制：ZAB 协议
  - 三、Leader 选举机制
  - 四、集群部署要点
  - 五、优势与挑战

Zookeeper 集群是一个由多个 Zookeeper 服务实例组成的分布式协调服务系统， 通过奇数个节点（通常 3、5、7 个）的协作，提供高可用性、容错性和数据一致性，适用于分布式环境下的配置管理、命名服务、分布式锁等场景。以下从架构、核心机制、选举机制、数据模型、应用场景及部署要点六个方面展开介绍：

一、集群架构：Leader-Follower 模式

角色分工：
- Leader：唯一处理所有写请求的节点，通过 ZAB 协议（Zookeeper Atomic Broadcast）将数据变更同步至 Follower 节点，确保全局数据一致性。
- Follower：处理客户端读请求，参与 Leader 选举，并在选举中投票。当 Leader 故障时，Follower 通过投票选出新 Leader。
- Observer（可选）：扩展读取负载，不参与投票，适合高并发读场景。
节点数量：通常为奇数（如 3、5、7），以保证在部分节点故障时仍能通过多数派（quorum）机制维持服务可用性。

tips:后续详细介绍Follower和Observer的区别和关系

二、核心机制：ZAB 协议

原子广播：确保所有写操作按顺序执行，要么全部成功，要么全部失败。
崩溃恢复：当 Leader 故障时，通过选举产生新 Leader，并同步最新数据至所有节点，保证最终一致性。
数据一致性：每个节点保存相同数据副本，客户端无论连接哪个节点，读取的数据均一致。

三、Leader 选举机制

选举触发条件：
- 集群初始化启动。
- Leader 节点崩溃或与集群失去连接。
选举规则：
1. EPOCH 优先：每个 Leader 任期的代号，EPOCH 大的节点直接胜出。
2. 事务 ID（ZXID）次之：EPOCH 相同时，ZXID 大的节点胜出（ZXID 标识服务器状态变更，数值越大表示数据越新）。
3. 服务器 ID（SID）兜底：ZXID 相同时，SID 大的节点胜出（SID 为节点唯一标识，如 server.1、server.2）。
选举过程示例：
- 假设集群有 5 个节点（SID 1-5），初始时 SID 3 为 Leader。
- 若 SID 3 和 5 故障，剩余节点启动选举，SID 4 发起投票但因票数不足（需半数以上，即 3 票）无法当选。
- 最终，SID 3 恢复或新节点加入后，通过 ZXID 或 SID 比较选出新 Leader。

四、集群部署要点

环境准备：
- 至少 3 台服务器，确保低延迟、高带宽网络连接。
- 安装 JDK 8+，关闭防火墙或开放 2181（客户端端口）、2888（Follower 与 Leader 通信）、3888（选举端口）。

配置文件（zoo.cfg）：

tickTime=2000          # 心跳间隔（毫秒）
initLimit=10           # Follower 初始连接 Leader 的超时时间（tickTime 倍数）
syncLimit=5            # Follower 同步 Leader 数据的超时时间
dataDir=/data/zookeeper # 数据快照目录
clientPort=2181        # 客户端连接端口
server.1=192.168.1.1:2888:3888  # 节点 1 配置
server.2=192.168.1.2:2888:3888  # 节点 2 配置
server.3=192.168.1.3:2888:3888  # 节点 3 配置

节点标识（myid）：
- 在 dataDir 目录下创建 myid 文件，内容为节点编号（如 1、2、3），与 zoo.cfg 中的 server.X 对应。
启动与验证：
- 依次启动各节点：./zkServer.sh start。
- 检查状态：./zkServer.sh status，正常应显示 1 个 Leader 和多个 Follower。
- 使用客户端测试：./zkCli.sh -server 192.168.1.1:2181，执行 ls / 查看根节点。

五、优势与挑战

优势：
- 强一致性：通过 ZAB 协议保证数据最终一致。
- 高可用性：奇数节点设计容忍部分节点故障。
- 轻量级：适合高并发读场景（如配置中心）。
挑战：
- 写性能瓶颈：写操作需同步至多数节点，密集写入时可能成为瓶颈。
- 运维复杂：需监控网络分区、脑裂等问题。
- 依赖网络：节点间通信延迟影响性能。