ZooKeeper 如何实现分布式事务？

1. 核心机制：ZAB 协议（ZooKeeper Atomic Broadcast）

ZooKeeper 通过 ZAB 协议保证分布式事务的原子性和一致性。ZAB 协议类似于两阶段提交（2PC），但更高效：

• Leader 选举：集群选出一个 Leader 处理事务请求。
• 事务广播：
  1. 提案阶段：Leader 将事务操作广播给所有 Follower。
  2. 提交阶段：当超过半数 Follower 确认后，Leader 提交事务并通知所有节点生效。

2. 关键特性

• 顺序一致性：所有事务按全局顺序执行（通过 ZXID 全局唯一事务 ID 实现）。
• 原子性：事务要么在所有节点生效，要么全部失败。
• 持久性：事务日志持久化到磁盘，宕机可恢复。
• Watch 机制：客户端可监听节点变化，实时感知事务结果。

3. 实战场景：分布式锁实现事务隔离

假设电商系统扣减库存：

// 创建分布式锁节点
String lockPath = zk.create("/order/lock_001", null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
try {
    // 获取锁成功，执行业务
    reduceStock(); // 扣减库存
    createOrder(); // 创建订单
} finally {
    zk.delete(lockPath, -1); // 释放锁
}

• EPHEMERAL 节点：客户端断开时自动删除，避免死锁。
• Watch 监听：其他客户端监听锁节点释放事件。

4. 与 2PC 的区别

5. 注意事项

• 不是数据库事务：ZooKeeper 仅提供协调能力，业务数据需存储在其他数据库（如 MySQL）。
• 适用场景：
  • 分布式锁（如 Redis 的 RedLock 替代方案）
  • 配置管理（实时同步全局配置）
  • 选主（如 Kafka Controller 选举）

总结

ZooKeeper 通过 ZAB 协议实现分布式事务的核心能力：

1. 原子提交：基于过半确认机制保证事务原子性。
2. 顺序执行：通过 ZXID 确保全局操作顺序。
3. 实时通知：Watch 机制让客户端感知状态变化。
4. 高可用：Leader 选举机制应对节点故障。

✅ 关键点：ZooKeeper 不直接处理业务数据事务，而是通过协调分布式节点间的状态与顺序，为上层应用提供事务一致性保障。