ZooKeeper一致性与写请求链路
理解一致性保证和写请求完整处理流程。
顺序一致性保证
一致性层次：
| 层次 | 说明 |
|---|---|
| FIFO顺序 | 单客户端请求按序执行 |
| 全局顺序 | 所有写请求全局有序 |
- 最终一致 | 所有节点最终数据相同 |
FIFO顺序保证：
text
客户端A发送请求: R1, R2, R3
执行顺序: 必须按R1→R2→R3顺序
全局顺序保证：
text
所有客户端的写请求
Leader按ZXID顺序处理
所有节点按ZXID顺序看到
一致性约束：
| 约束 | 说明 |
|---|---|
| 单客户端顺序 | 同客户端请求不能乱序 |
| 跨客户端顺序 | 不同客户端请求全局有序 |
| 可见性顺序 | 所有节点看到相同顺序 |
一致性示例：
text
客户端A: create /node "data1"
客户端B: set /node "data2"
所有节点必须先看到create，再看到set
顺序一致，不能颠倒
弱一致性说明：
text
读请求可能在Follower执行
Follower数据可能有短暂延迟
但最终所有节点数据一致
注意：读请求可能读到旧数据，强一致读需访问Leader。
写请求处理链路
完整链路：
text
客户端 → Follower → Leader → 所有Follower → 过半ACK → 提交 → 响应
详细流程：
text
1. 客户端发送写请求
2. Follower转发请求给Leader
3. Leader生成Proposal提议
4. Leader发送Proposal给所有Follower
5. Follower写入日志，发送ACK
6. Leader统计ACK
7. 过半ACK后Leader发送Commit
8. 所有节点执行提交
9. Leader响应客户端成功
时间节点：
| 阶段 | 时间 |
|---|---|
| 请求转发 | 网络延迟 |
| 提议生成 | <1ms |
| ACK收集 | 网络延迟 |
| 提交执行 | <1ms |
写请求限制：
| 限制 | 说明 |
|---|---|
| Leader处理 | 所有写请求必须Leader处理 |
| 过半确认 | 必须过半节点确认 |
| 顺序执行 | 按ZXID顺序执行 |
写性能因素：
| 因素 | 影响 |
|---|---|
| 节点数量 | 更多节点=更多ACK等待 |
| 网络延迟 | 高延迟=ACK收集慢 |
| 批量处理 | 批量提议优化吞吐 |
写请求失败处理：
| 失败原因 | 处理 |
|---|---|
| Leader宕机 | 等待选举恢复 |
| 节点不足 | 无法过半确认 |
| 版本冲突 | 返回BadVersion |
提示：写性能取决于网络延迟和节点数量，不适合高写场景。
要点总结
- FIFO保证单客户端请求按序执行
- 全局顺序保证所有写请求有序
- 读请求可能读到旧数据，强一致读需访问Leader
- 写请求链路：转发→提议→ACK→提交→响应
- 所有写请求必须Leader处理
- 过半节点确认才能提交
- 写性能受网络延迟和节点数影响
📝 发现内容有误？点击此处直接编辑