Raft vs ZAB 深度解析

将臣三代

已于 2025-05-01 19:21:15 修改

阅读量1.3k

点赞数 18

分类专栏： Java面试专项文章标签： raft zab 分布式分布式一致性协议面试技术选型架构设计

于 2025-04-30 16:46:15 首次发布

本文链接：https://blog.csdn.net/yaoqiancuo3276/article/details/147636167

版权

24 篇文章

订阅专栏

通过选举产生 Leader，所有写操作只通过 Leader，Follower 被动同步 Leader 日志。

模块	说明
Leader Election（选主）	超时未收到心跳，转 Candidate，发起投票，过半即成 Leader
Log Replication（日志复制）	Leader 收到客户端请求，将请求作为日志广播到大多数 Follower
Commit Index（提交控制）	Leader 收到超过半数的成功 AppendEntries响应后，标记日志为提交状态
Apply to State Machine（应用到状态机）	各节点将已提交日志按顺序应用，保证一致性
Term 任期机制	每次选举产生新的 Term，防止 Leader 冲突

Candidate: 超时发起选举 → 赢得过半选票 → 成为 Leader
Leader: 处理所有写请求 → 日志广播 → 过半确认后 Commit → 广播提交通知
Follower: 只被动接收日志并执行

Zookeeper 特有的一致性协议，强调事务原子广播，特别适合频繁读+少量写场景。

模块	说明
Leader Election（崩溃恢复选举）	选出最新事务ID（Zxid）最大节点为新Leader
Log Synchronization（数据同步）	新Leader收集Follower最新日志，统一数据
Atomic Broadcast（事务广播）	Leader向所有节点广播 Proposal，Follower写日志，过半ACK后Commit
State Synchronization（应用状态同步）	Follower接收Commit通知并应用到状态机

客户端写请求 -> Leader创建Proposal -> Proposal广播给Follower -> 
Follower写入WAL并Ack -> Leader收半数Ack -> 发Commit广播 ->
 所有Follower Apply

比较维度	Raft	ZAB
应用系统	Etcd、Consul、TiKV、CockroachDB	Zookeeper
适合场景	需要频繁写操作、存储KV型数据	以协调服务（如分布式锁、选主）为主，读多写少
容错机制	Term机制切换，快速选主	Zxid选主，重日志同步恢复
成熟度	大量开源社区实践	Zookeeper内部专用，单一适配性
写性能	一般偏慢（单主负载）	写非常慢（重同步）
读性能	Leader强一致读 or 可配置读Follower（读写平衡）	支持Follower读（读请求分散，读多系统优秀）

两者都在保证**强一致性（CP方向）**上非常强大，但场景侧重完全不同。

五、性能瓶颈对比总结

场景	Raft 瓶颈	ZAB 瓶颈
写多场景	Leader负载、同步放大	全局广播带宽/延迟爆炸
节点恢复	Follower日志追赶拉慢集群性能	Leader需要同步大量数据导致崩溃恢复慢
网络波动	心跳超时频繁触发选主	Proposal超时、广播延迟叠加
高并发	Leader负载瓶颈，需强制限流	Proposal压力集中在Leader，Follower回Ack慢