Raft 和 ZAB 是分布式系统中两种主流的“共识算法”，核心目标均为解决“分布式节点数据一致性”和“高可用”问题，但设计细节和适用场景存在差异，具体异同点如下：
一、相同点（核心目标与底层逻辑一致）
1.核心目标一致：均需在分布式环境中（节点故障、网络延迟/分区），确保所有节点数据的“一致性”（数据内容和执行顺序统一）和集群“高可用”（故障后快速恢复服务）。
2.基于“leader 主从架构”：均采用“一主多从”模式，所有写请求统一由 leader 处理，再同步给 follower，避免多节点并发写导致的数据混乱。
3.依赖“多数派确认”：无论 leader 选举还是数据同步，均要求“超过半数节点确认”（如 3 节点需 2 个确认、5 节点需 3 个确认），以此避免“脑裂”（集群分裂为多个小集群各自选 leader）。
4.事务/日志全局有序：均通过“全局唯一且递增的 ID”（Raft 的 Term+Index、ZAB 的 Epoch+序列号）标记操作顺序，确保所有节点按相同顺序执行操作，避免数据覆盖或顺序混乱。
5.日志先行机制：所有写操作（事务/日志条目）在执行前，均先写入节点本地日志（持久化存储），即使节点崩溃，重启后可通过日志恢复数据，避免丢失。
二、不同点（设计细节与适用场景差异）
| 对比维度 | Raft 算法 | ZAB 算法（ZooKeeper 专属） |
|---|---|---|
| 定位与适用场景 | 通用共识算法，可独立实现（如 Etcd、Consul），适用于“通用分布式一致性需求”（如配置同步、服务发现）。 | 专为 ZooKeeper 设计的“原子广播协议”，深度绑定 ZooKeeper 的数据模型（如节点层级结构、Watcher 机制），不单独对外提供。 |
| 核心模式划分 | 明确分为“Leader 选举”“日志复制”“安全（Safety）”三个独立模块，逻辑更解耦，易理解和实现。 | 分为“恢复模式（Recovery Mode）”和“广播模式（Broadcast Mode）”，选举和数据恢复合并在“恢复模式”中，逻辑更紧凑。 |
| Leader 选举规则 | 选举时，节点先比较“Term（任期，每次选举+1）”，Term 大的优先；Term 相同则比较“日志最后一条的 Index（序列号）”，Index 大的优先（即“数据最新的节点优先”）。 | 选举核心依据是“ZXID（由 Epoch+序列号组成）”，直接比较 ZXID 大小：Epoch 大的优先，Epoch 相同则序列号大的优先（逻辑与 Raft 一致，但未单独拆分“Term”概念）。 |
| 数据同步机制 | Leader 对 follower 采用“日志复制（Log Replication）”：将未同步的日志条目逐条发送给 follower，follower 确认后，Leader 再通知所有节点“提交（Commit）”。 | Leader 对 follower 采用“事务同步”：恢复模式下，新 Leader 会先将 follower 缺失的事务（ZXID 不完整的部分）批量同步，确保所有 follower 日志与 Leader 一致后，才进入广播模式。 |
| 读请求处理 | 默认允许 follower 处理读请求（可配置为“仅 Leader 处理”），但需通过“Read Index”或“Lease Read”机制保证读一致性（避免读取到旧数据）。 | 所有读请求默认路由到 Leader（ZooKeeper 可配置“follower 读”，但需容忍“最终一致性”），follower 处理读请求时，需先确认自身与 Leader 数据同步完成。 |
| 设计侧重点 | 追求“易理解性”，将复杂逻辑拆分为独立模块（如明确的 Term 概念、分阶段选举），降低实现门槛，适合作为通用共识算法推广。 | 追求“与 ZooKeeper 深度适配”，优化 ZooKeeper 特有的“短事务、高频读写”场景（如配置变更、节点创建），更注重性能与 ZooKeeper 功能的协同。 |
三、总结
-
共性：二均者是“leader 主从架构+多数派确认”的共识算法，解决的核心问题（一致性、高可用）和底层逻辑（日志有序、持久化）高度相似。
-
差异：Raft 是“通用、易实现”的共识算法，适用于各类分布式系统；ZAB 是“ZooKeeper 专属、深度优化”的协议，更贴合 ZooKeeper 的数据模型和业务场景，不具备通用性。
