01

60 秒回答模板

ZooKeeper 通过事务日志、快照和 Zab 协议降低已提交数据丢失风险。写请求由 leader 排序并分配 zxid，先写事务日志，再广播给 follower；超过半数节点持久化并 ack 后才提交。节点重启时用快照加事务日志恢复状态，选主时会比较 epoch 和 zxid，尽量让包含最新已提交事务的节点成为 leader。多数派机制保证任意两个多数派有交集，从而避免已提交事务在新 leader 中消失。

考点 核心机制与工程取舍
难度 中高频面试题
回答目标 按定义、机制、场景讲清楚
02

深入解析

01

持久化基础

ZooKeeper 不只靠内存保存数据。事务日志记录每次状态变更，快照保存某个时刻的数据树，用于缩短重启恢复时间；恢复时先加载快照，再回放后续日志。

02

写入排序

所有写请求由 leader 统一排序并分配 zxid。zxid 体现全局写入顺序，后续恢复、同步和选主都依赖它判断日志新旧。

03

多数派提交

事务不是 leader 本地写完就提交，而是需要过半 follower 记录并确认。多数派交集保证新一轮 leader 选举中至少有一个节点见过已提交事务。

04

选主与同步

选主会倾向选择 epoch、zxid 更新的节点。新 leader 建立后，会让 follower 做差异同步、截断未提交日志或补齐缺失日志，保证集群收敛到同一前缀。

05

边界条件

已提交数据的可靠性依赖磁盘刷写策略、过半节点存活和正确运维。未达到多数派的提案可能在故障后回滚；如果多数节点同时丢盘或误删数据，协议无法凭空恢复。

03

易错点

  • 只说过半机制，不提事务日志和快照恢复。
  • 认为 leader 本地写成功就代表事务已提交。
  • 把未提交提案和已提交事务混为一谈。
  • 忽略 ZooKeeper 适合小数据协调，不适合当大容量 KV 存储。
04

面试官追问

快照能单独保证数据不丢吗？

不能。快照只保存某一刻状态，快照之后的更新必须靠事务日志恢复，所以两者要配合。

为什么过半确认能保证已提交事务不丢？

因为任意两个多数派有交集，新 leader 的选举多数派中至少有节点包含已提交事务，协议会选择并同步较新的日志。

未提交的事务故障后会怎样？

可能被丢弃或回滚。只有达到提交条件的事务才应该对客户端承诺成功，未提交提案不能当成可靠数据。

ZooKeeper 适合存大数据吗？

不适合。它适合小规模元数据、配置和协调状态，过大的节点数据会拖慢同步、快照和内存占用。