-
前言：为什么理解一致性协议，是成为架构师的分水岭？
- 分布式系统都绕不开一致性
- MQ、注册中心、配置中心、KV 存储、数据库副本全靠它
- 但多数开发只“会用，不会理解”
-
为什么需要一致性协议？
- 多副本存储
- Leader 选举
- 元数据一致
- 跨节点日志复制
- 网络分区下仍需保持一致性
-
三大经典协议对比
协议 优点 缺点 应用场景 Paxos 理论最强 工程落地难 数据库、分布式元数据 Raft 工程友好 Leader 压力集中 etcd、Consul、TiKV Zab 顺序广播 依赖 ZooKeeper ZooKeeper -
Raft 的工程核心机制
- Leader 选举
- 日志复制（AppendEntries）
- 安全性保证
- 一致性读
- Snapshot + 压缩日志
-
一致性协议的工程难点
- 网络抖动导致多 Leader 竞争
- 日志不一致 → 覆盖问题
- 全量同步耗时巨大
- 写入压力一股脑压到 Leader
-
真正企业级的落地方案
- 多 Region 分区 + 局部一致
- 读写分离策略（弱一致读）
- Leader Rotation 技术
- Raft Proxy 层（隐藏底层复杂性）
-
案例：配置中心（Config Center）的一致性实现
- 配置发布 → 写入 Leader → 日志复制 → 多节点同步
- Client Watch → 增量通知 → 最终一致性生效
- 如何避免“脑裂”？
- 如何保证变更可回放？
-
总结
- Paxos 是理论
- Raft 是工程
- 理解一致性协议，才能真正看懂云原生时代的基础设施
