ZooKeeper崩溃恢复机制
崩溃恢复保证集群故障后数据一致性。
崩溃恢复机制
恢复触发条件：
| 条件 | 说明 |
|---|---|
| Leader宕机 | Follower心跳超时检测 |
| Leader网络断开 | 连接检测超时 |
| Follower重启 | 重新加入集群 |
恢复流程：
text
1. Follower检测Leader故障
2. 状态变LOOKING，发起选举
3. 选出新Leader（ZXID最大者优先）
4. 新Leader生成新Epoch
5. Leader与Follower数据同步
6. 同步完成后集群恢复服务
数据同步方式：
| 方式 | 说明 | 触发条件 |
|---|---|---|
| DIFF | 发送差异事务 | Follower落后少量 |
| TRUNC | 截断未提交事务 | Follower有未提交数据 |
| SNAP | 发送完整快照 | Follower落后大量 |
DIFF同步：
text
Leader比较Follower ZXID
发送差距范围内的事务日志
Follower回放事务达到同步
TRUNC同步：
text
Follower ZXID > Leader committed ZXID
说明Follower有旧Leader未提交提议
截断到Leader committed ZXID
Epoch更新：
text
新Leader生成新Epoch
新Epoch必须 > 旧Epoch
ZXID = Epoch + Counter
保证新提议优先于旧提议
注意：Epoch机制防止旧Leader"假复活"影响数据一致性。
事务ID(ZXID)设计
ZXID结构：
text
ZXID = 高32位Epoch + 低32位Counter
高32位: Leader纪元，每次选举递增
低32位: 事务计数器，每次写递增
ZXID示例：
text
Epoch=1, Counter=5 → ZXID=0x0000000100000005
选举后Epoch递增:
Epoch=2, Counter=0 → ZXID=0x0000000200000000
Epoch作用：
| 作用 | 说明 |
|---|---|
| 标识Leader任期 | 每次选举Epoch递增 |
| 区分新旧提议 | 新Epoch提议优先 |
| 防止假复活 | 旧Leader提议无效 |
Counter作用：
| 作用 | 说明 |
|---|---|
| 事务顺序 | 同Epoch内递增 |
| 全局唯一 | 每个事务唯一ID |
| 一致性保证 | 按Counter顺序提交 |
ZXID比较规则：
text
比较ZXID大小:
先比较Epoch → Epoch大者优先
Epoch相同 → 比较Counter → Counter大者优先
ZXID应用：
| 应用 | 说明 |
|---|---|
| 选举 | ZXID最大者优先当选 |
| 同步 | 根据ZXID差距同步 |
| 恢复 | Epoch递增防止冲突 |
提示：ZXID是ZooKeeper一致性的核心标识，贯穿所有流程。
要点总结
- 崩溃恢复流程：选举、同步、Epoch更新
- DIFF/TRUNC/SNAP三种同步方式
- Epoch每次选举递增，防止旧Leader影响
- ZXID = Epoch(高32位) + Counter(低32位)
- Epoch标识Leader任期，Counter标识事务顺序
- ZXID比较：Epoch优先，Counter次优
- ZXID最大者优先当选Leader
📝 发现内容有误？点击此处直接编辑