zookeeper通过zab协议实现数据一致性，其核心包括leader选举、事务广播与状态同步。集群中由leader处理写操作，follower参与投票与数据同步。节点启动或故障恢复时进入恢复模式，分为发现和同步两阶段：发现阶段follower上报自身最大zxid，leader据此确定最新状态；同步阶段leader推送缺失的事务日志，确保follower数据追平。正常运行时，leader将写请求封装为提案，多数follower确认并持久化后提交，保证原子性与一致性。通过心跳机制监控节点存活，超时则触发新选举，确保系统高可用。zab协议结合选举、日志同步与原子广播，实现强一致与容错能力。
ZooKeeper 通过 ZAB 协议（ZooKeeper Atomic Broadcast）来保证主从节点之间的状态同步。这个协议的核心目标是确保所有节点的数据一致性，即使在部分节点故障或网络分区的情况下也能正常工作。
主从架构与角色划分
ZooKeeper 集群中通常包含一个Leader和多个Follower（以及可选的 Observer）。所有写操作必须通过 Leader 处理，Follower 节点负责参与投票和数据同步。
节点启动或 Leader 宕机后，集群会通过选举产生新的 Leader。一旦 Leader 确定，就开始进行状态同步。
ZAB 协议的两个阶段：发现与同步
ZAB 协议在恢复模式下分为两个关键阶段：
- 发现（Discovery）：Follower 向候选 Leader 发送自己的最大事务 ID（ZXID），Leader 收集这些信息以确定最新的数据状态。
- 同步（Synchronization）：Leader 根据 Follower 的 ZXID 决定需要推送哪些事务日志，使 Follower 的状态追赶到与 Leader 一致。
这个过程确保了即使某些 Follower 落后，也能被正确补全数据。
事务广播与持久化
在正常服务阶段，所有写请求由 Leader 发起事务广播：
- Leader 将写操作封装为事务提案（Proposal），并发送给所有 Follower。
- Follower 接收到提案后，先写入本地事务日志，再返回 ACK。
- 当多数节点确认后，Leader 提交事务，并通知所有 Follower 更新内存状态。
这种基于多数派确认的机制，既保证了数据一致性，也具备容错能力。
心跳与异常处理
Leader 和 Follower 之间通过心跳维持连接。如果 Follower 长时间未收到心跳，会重新进入选举流程。同样，若 Leader 失去多数 Follower 的响应，也会自动退出 Leader 角色。
这种设计使得系统在节点宕机或网络波动时能快速恢复一致性。
基本上就这些。ZooKeeper 利用 ZAB 协议实现了高可用和强一致性的状态同步，核心在于选举、日志同步和原子广播机制的配合。不复杂但容易忽略细节。
