Zookeeper 如何通过 ZAB 协议保证数据一致性？

Zookeeper 的一致性主要靠 ZAB 协议保证。所有写请求最终交给 Leader 排序，Leader 分配全局递增的 zxid，再把提案广播给 Follower；超过半数节点 ACK 后，事务才提交。代价是写入要等多数派，延迟不会像单机缓存那样低；好处是 Leader 宕机后，新 Leader 能根据 zxid 找到较完整的提交历史，避免已提交数据丢失或未提交数据乱入。

追问

ZAB 和普通主从复制最大区别是什么？

普通主从复制常见问题是主节点确认太早，故障时从节点未必拥有同一批数据。ZAB 要求事务拿到多数派 ACK 再提交。

zxid 为什么能决定数据新旧？

zxid 是事务全局序号，高位通常关联 Leader epoch，低位表示任期内事务递增。选主和同步时比较 zxid 判断谁更新。

读请求为什么不一定强一致？

Follower 和 Observer 异步接收提交消息，可能比 Leader 慢。必须读最新时可以先执行 sync()，但有协调成本。

Leader 崩溃时怎么避免事务丢失？

新 Leader 会和其他节点对齐事务日志：落后的补发 DIFF，差太多的发 SNAP，未提交尾巴会 TRUNC 回滚。

怎么判断一致性问题来自哪里？

先确认节点角色和存活，再看日志里的 zxid、leader election、syncLimit 超时。很多读旧值只是连到了落后 Follower。