Zookeeper事务处理机制是怎样的

核心概念与一致性保证

• ZooKeeper 将改变服务器状态的请求称为事务，每个事务会被分配一个全局唯一、单调递增的ZXID（64位）：高 32 位是epoch（Leader 任期/代），低 32 位是事务计数器；ZXID 既标识事务顺序，也标识 Leader 周期，保证跨周期的事务不会混淆。写操作只能由Leader处理，读操作可由 Follower/Observer 直接响应。ZooKeeper 提供全局可线性化写入与客户端 FIFO 顺序保证，即来自同一客户端的请求按发送顺序执行，跨客户端按 ZXID 的全局顺序提交。

事务生命周期与 ZAB 协议

• 运行模式：集群在崩溃恢复模式与消息广播模式间切换。崩溃恢复用于选主与数据对齐，消息广播用于正常写入复制。
• 写入路径（消息广播，类 2PC）：
  1. 客户端写请求到达任一服务器；非 Leader 会转发给 Leader。
  2. Leader 为该请求生成Proposal + ZXID并广播给所有 Follower。
  3. Follower 将 Proposal 写入本地事务日志后返回 ACK。
  4. 当收到过半（含 Leader）ACK后，Leader 广播Commit；各节点提交到内存数据库（ZKDatabase），并返回结果给客户端。
  5. 通过队列与 FIFO 策略保证顺序与解耦，提高吞吐。
• 崩溃恢复：Leader 失效时进入恢复，新 Leader 需拥有最大 ZXID的日志，从而提交已被提交的事务、丢弃未提交的事务；随后与多数派进行数据同步，再进入广播阶段对外服务。

客户端多操作原子性与版本控制

• 多操作原子性：客户端可通过multi/事务 API将多个 create/delete/setData/check 操作打包，服务端以原子方式执行，任一操作失败则整个事务不生效（无部分提交）。
• 版本检查：如 setData/delete 支持基于版本号（version）的检查-设置（check-and-set），用于实现乐观并发控制与条件更新；版本不匹配则操作失败，需要业务侧重试或读取最新状态后再尝试。

关键特性与常见误区

• 关键特性
  • 顺序一致性：全局按 ZXID 有序，客户端按发送顺序执行。
  • 原子性：事务要么全部成功，要么全部失败；多操作打包具备原子性。
  • 单一系统映像：任一时刻不同客户端看到的数据视图一致。
  • 可靠性与持久性：已提交事务引起的状态变更会被持久化，并在下个变更前保留。
  • 实时性与可用性权衡：写入需多数派确认，读可就近（Follower/Observer）提升吞吐。
• 常见误区
  • 不是通用分布式事务协调器：ZooKeeper 的“事务”指对数据树的变更与原子广播，不等同于跨系统 2PC/XA 事务。
  • read-your-writes 需会话黏连或就近读：跨会话或跨节点读取可能暂时看不到刚写入的数据，需通过本地读/会话保持/监听等手段保证读后一致性体验。