zookeeper Curator(5):集群架构和集群搭建

一、集群架构：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。

四、集群部署要点

1. 环境准备：
   • 至少 3 台服务器，确保低延迟、高带宽网络连接。
   • 安装 JDK 8+，关闭防火墙或开放 2181（客户端端口）、2888（Follower 与 Leader 通信）、3888（选举端口）。
2. 配置文件（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 配置
   

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

五、优势与挑战

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