ZooKeeper集群架构原理
理解集群规模和选举机制是运维基础。
集群节点数量要求
奇数节点原则：
| 规则 | 说明 |
|---|---|
| 最小规模 | 3节点 |
| 推荐规模 | 3、5、7节点 |
| 不推荐偶数 | 奇数更经济 |
过半机制：
Bash
过半节点存活 → 集群可服务
少于过半存活 → 集群停止
节点数计算：
| 节点数 | 过半数 | 最大容忍故障 |
|---|---|---|
| 3 | 2 | 1节点故障 |
| 4 | 3 | 1节点故障 |
| 5 | 3 | 2节点故障 |
| 6 | 4 | 2节点故障 |
| 7 | 4 | 3节点故障 |
为什么奇数节点：
text
对比3节点和4节点：
3节点：容忍1故障，成本3节点
4节点：容忍1故障，成本4节点
偶数节点不增加容错能力，浪费资源
规模选择建议：
| 场景 | 推荐规模 |
|---|---|
| 测试环境 | 3节点 |
| 生产环境 | 3节点或5节点 |
| 高可用要求 | 5节点或7节点 |
注意：节点数过多会增加选举和同步延迟。
Leader选举基本概念
选举触发条件：
| 场景 | 说明 |
|---|---|
| 集群启动 | 所有节点状态LOOKING |
| Leader宕机 | Follower心跳超时 |
| Leader网络断开 | Follower检测连接失败 |
选举流程概述：
text
1. 节点状态变为LOOKING
2. 各节点发起投票提议
3. 投票信息包含：ZXID、myid
4. ZXID最大者优先成为Leader
5. ZXID相同则myid大者优先
6. 获得过半投票者成为Leader
7. 其他节点成为Follower
投票规则：
| 规则 | 说明 |
|---|---|
| ZXID优先 | 数据最新者优先 |
| myid次优 | ZXID相同myid大者优先 |
| 过半机制 | 获得过半投票才当选 |
选举状态：
| 状态 | 说明 |
|---|---|
| LOOKING | 正在选举 |
| LEADING | Leader角色 |
| FOLLOWING | Follower角色 |
选举时间：
text
electionTime = initLimit × tickTime
默认: 10 × 2000ms = 20秒
选举验证：
text
# 查看选举后的角色
zkServer.sh status
# 输出: Mode: leader 或 Mode: follower
提示：ZXID越大表示数据越新，优先成为Leader保证数据完整。
要点总结
- 集群最小3节点，推荐奇数节点
- 过半节点存活即可服务
- 奇数节点比偶数更经济，容错能力相同
- Leader选举基于过半投票机制
- ZXID最大者优先当选Leader
- 选举状态：LOOKING选举、LEADING领导、FOLLOWING跟随
📝 发现内容有误？点击此处直接编辑