架构（06）：分布式一致性——CAP、BASE、Raft/Paxos、分布式事务
更新时间：2026-09-02。本文是
architecture/架构领域第 06 篇，接 消息驱动架构。分布式一致性是所有分布式系统绕不开的难题。CAP 定理告诉你必须取舍，BASE 告诉你最终一致性是可接受的，Raft/Paxos 帮你实现强一致，分布式事务在业务层解决跨服务一致。
本文要回答的问题
- CAP 定理三个选两个，怎么选？
- BASE 是什么？和 ACID 是什么关系？
- Raft 和 Paxos 是什么？怎么选？
- 分布式事务方案对比：XA vs 2PC vs 3PC vs Saga vs TCC？
一、CAP 定理
CAP = Consistency（一致性）+ Availability（可用性）+ Partition Tolerance（分区容错性）
只能三选二，不能三者兼得
C：一致性，所有节点看到相同数据
A：可用性，每个请求都能得到响应
P：分区容错性，网络分区时系统仍然能工作
实际：P 必须选，因为在分布式系统中，网络分区一定会发生
所以：实际是在 CP 和 AP 之间选
CP（一致 + 分区）：
网络分区，拒绝写，保证一致
示例：ZooKeeper、Etcd
AP（可用 + 分区）：
网络分区，继续写，各节点数据可能不一致
示例：Eureka、DNS
不选 C（放弃一致性）：
最终一致性，数据最终一致
大部分分布式系统实际选 AP，因为可用性不能丢
结论：CAP 不是三选二，而是 P 必选，C 和 A 二选一。CAP 选型建议：
| 场景 | 选型 | 理由 |
|---|---|---|
| 配置中心、注册中心 | CP | 一致比可用重要，配置错了麻烦 |
| 用户服务、订单服务 | CP | 数据不能错 |
| 商品列表、搜索 | AP | 可用比一致重要，暂时不一致还能看 |
| 日志、监控 | AP | 最终一致就行，不要求实时 |
二、BASE 理论
BASE = Basically Available（基本可用）+ Soft State（软状态）+ Eventual Consistency（最终一致性）
BASE 是 CP 的妥协，接受最终一致性
基本可用：系统大部分时间可用，允许部分不可用
软状态：中间状态，数据可以不一致
最终一致性：数据最终一致，但中间可以有短暂不一致
BASE vs ACID：
ACID：强一致，适合单体数据库
BASE：最终一致，适合分布式系统
BASE 是分布式系统的默认选择：
大部分业务不需要强一致
最终一致性足够了
比如：订单创建后，库存扣减可以延迟几秒BASE 实际应用：
- 分布式缓存：缓存和数据库最终一致
- 异步消息：消息最终到达
- 数据同步：主从库最终一致
- 电商订单：下单后，扣库存、支付、物流都是最终一致
三、Raft 共识算法
Raft 是分布式共识算法，保证多个节点达成一致
Raft 核心概念：
Leader：领导者，负责写操作
Follower：跟随者，复制 Leader 的数据
Candidate：候选者，Leader 挂了，竞选新 Leader
Raft 流程：
1. Leader 选举：Follower 如果超时没收到 Leader 心跳，变成 Candidate，发起选举
2. 日志复制：Leader 写日志，复制到 Follower，多数确认后提交
3. 安全性：只有最新日志的节点能当选 Leader
Raft 协议特点：
- 易懂，比 Paxos 好学
- 强 Leader，所有写走 Leader
- 最多一个 Leader，保证数据一致性
- 日志复制 + 多数确认，保证一致
Raft 应用：
- Etcd（Kubernetes 的配置中心）
- Consul
- TiKV
- 大多数分布式数据库都用 RaftRaft 为什么比 Paxos 流行：
- Raft 更易懂，Paxos 抽象难懂
- Raft 有明确的 Leader，更容易理解
- Raft 有明确的日志复制流程
- 工业界 Raft 已经广泛使用，Paxos 在学术上知名
四、Paxos 协议
Paxos 是分布式共识算法，比 Raft 更早提出
Paxos 角色：
Proposer：提出提案
Acceptor：接受提案
Learner：学习提案结果
Paxos 流程（两阶段）：
1. Prepare：Proposer 发 Prepare 到 Acceptors，获取多数确认
2. Accept：Proposer 发 Accept 到 Acceptors，如果多数接受，提案通过
Paxos 变体：
Multi-Paxos：多个 Paxos 实例，连续达成共识
Fast Paxos：减少通信轮次，性能更好
Paxos 应用：
Google Chubby（分布式锁服务）
Zookeeper ZAB 协议（ZooKeeper 的原子广播，类似 Paxos）Raft vs Paxos：
| 对比 | Raft | Paxos |
|---|---|---|
| 易懂性 | 好，有教材 | 差，难理解 |
| Leader | 强 Leader | 弱 Leader 或无 Leader |
| 实现 | 工业界广泛使用 | 学术上多，工业用 Multi-Paxos 变体 |
| 可理解度 | 好 | 差 |
| 性能 | 差不多 | 差不多 |
选型： 新系统用 Raft，Paxos 太复杂，Raft 已经足够好。
五、分布式事务方案对比
| 方案 | 一致性 | 性能 | 复杂度 | 适用场景 |
|---|---|---|---|---|
| XA（两阶段提交 2PC） | 强一致 | 差 | 中 | 数据库之间 |
| 3PC（三阶段提交） | 强一致 | 差 | 高 | 很少用 |
| Saga | 最终一致 | 好 | 低 | 业务补偿 |
| TCC | 强一致 | 中 | 高 | 资金敏感 |
| 本地消息表 | 最终一致 | 好 | 低 | 消息可靠 |
| 事务消息 | 最终一致 | 好 | 中 | 消息可靠 |
1. XA/2PC（两阶段提交）
流程：
1. 准备阶段：协调者问所有参与者，准备好了吗？
2. 提交阶段：都准备好了，提交；有一个没准备好，回滚
缺点：
- 阻塞，资源锁定，性能差
- 协调者挂了，参与者一直卡住
- 不适合微服务
适用：同一数据库的事务，跨库不建议用2. TCC（Try-Confirm-Cancel）
TCC 是业务层的事务，不是数据库层
流程：
Try：预留资源
Confirm：确认使用
Cancel：取消释放
优点：强一致，性能好
缺点：实现复杂，每个服务都要实现 Try/Confirm/Cancel
适用：资金敏感，库存3. Saga
Saga 把长事务拆成多个本地事务，每个事务有补偿
优点：简单，不需要分布式事务
缺点：最终一致，补偿操作需要实现
适用：大部分业务场景选型建议：
- 简单业务：本地消息表 + 重试
- 大部分业务：Saga（编排或 Choreography）
- 资金敏感：TCC（强一致）
- 不要用 XA/2PC，性能差，不适合微服务
六、常见坑对照
| 错误 | 后果 | 对策 |
|---|---|---|
| 不理解 CAP，设计三选三 | 系统设计不符合实际 | 理解 CAP，P 必选，AC 二选一 |
| 用 XA 做微服务事务 | 性能差，阻塞 | 放弃 XA，用 Saga 最终一致 |
| 强一致场景选 AP | 数据不一致 | 敏感数据选 CP |
| 不处理脑裂 | 网络分区，数据冲突 | Raft 多数确认，避免脑裂 |
| 过度设计一致性 | 性能损失 | 能最终一致就最终一致 |
相关与延伸
下一篇：可观测性设计——Metrics/Logs/Traces 三支柱、OpenTelemetry；消息驱动架构，见 消息驱动架构——事件驱动、编排、死信。
一句话总结
分布式一致性：CAP 定理 P 必选，C 和 A 二选一，配置中心选 CP，商品列表选 AP；BASE 理论接受最终一致性，比 ACID 强一致更适合分布式系统；Raft 共识算法（Leader 选举 + 日志复制 + 多数确认）比 Paxos 更易懂，新系统用 Raft；分布式事务方案：XA/2PC 阻塞不推荐，TCC（Try-Confirm-Cancel）强一致适合资金敏感，Saga（本地事务 + 补偿）最终一致适合大部分业务；原则：能最终一致就最终一致，不要用强一致支付性能代价。