SAGA与Paxos/Raft：分布式事务与共识算法的本质区别与工程实践

先明确一件事：网上聊 SAGA 和 Raft 的时候，最常见的就是把两个词揉在一起对比，仿佛“分布式一致性”就是它们俩的全部。但说实话，这俩压根不是一个层面的东西。SAGA 是长事务拆分的补偿模式，处理的是业务状态最终一致；Paxos/Raft 是共识算法，解决的是分布式系统里各节点对某个值“达成一致”的问题。一个是业务设计模式，一个是底层一致性协议，放在一起对比是因为它们经常出现在同一个系统里，却总被混为一谈。

这篇文章我从实际落地角度出发，把 SAGA 和 Paxos/Raft 各自的核心原理、典型使用场景、踩坑经验、以及它们如何组合在一套分布式系统里各司其职，一次性讲清楚。

1. 概念纠偏：为什么 SAGA 和共识算法总被放在一起比较

1.1 两类算法的本质区别

先说结论：SAGA 和 Paxos/Raft 不属于同一个抽象层级，硬放在一起比“谁更重要”没有意义。

• Paxos/Raft 处理的是“多个节点对一个值达成一致”。典型场景：领导选举、分布式锁、复制状态机、配置同步。它们保证的是系统内部状态的一致性。
• SAGA 处理的是“一次跨多个服务的业务操作如何保证最终一致性”。典型场景：下单扣库存、支付账务、跨服务订单状态流转。它保证的是业务层面的最终一致。

用一个生活化类比来说：Paxos/Raft 解决的是“一群裁判如何对比赛结果达成共识”，SAGA 解决的是“一个大型比赛的多环节流程该如何设计，才能保证任何一个环节出错时整体成绩仍然有效”。

Paxos/Raft 关心的是数据在集群中能不能被正确复制、多数派是否同意同一个值；SAGA 关心的是业务从开始到结束经过多个微服务，中途某个服务失败后，系统能不能通过逆向补偿把状态恢复到一个合理的结果。

1.2 为什么会产生混淆

混淆的来源主要有三个：

1. 微服务架构普及后，分布式事务这个词被滥用，很多文章把 SAGA、TCC、2PC、Raft 一股脑归到“分布式一致性”大帽子下。
2. 一些中间件同时涉及两类机制。比如 etcd 使用 Raft 做共识，但它也提供事务 API；Seata 的 AT/TCC/SAGA 模式下，后端也可以依赖 Raft 类共识组件做高可用。
3. 面试题高频出现“SAGA 和 Raft 有什么区别”，导致大量开发者被训练成“把两个词对比”的思维模式。

正确的理解方式：共识算法是基础设施层的能力，SAGA 是业务编排层的模式。两者可以共存也可能互相配合，但不存在替代关系。

2. SAGA 与 Paxos/Raft 的核心机制深度拆解

2.1 Paxos 到底解决了什么问题

Paxos 由 Leslie Lamport 在 1990 年提出，论文因“古希腊议会”的寓言形式当年被评为过于晦涩，直到 1998 年才正式发表。它的核心目标：在一个可能发生节点宕机、网络分区、消息延迟的异步系统中，保证多个节点在某个提案上达成一致。

Paxos 的基本角色：

• Proposer：提出提案，值由客户端请求带入。
• Acceptor：接收提案，投票决定是否接受某个值。
• Learner：学习最终选定的值，不参与投票。

两阶段流程（Basic Paxos）：

1. Prepare 阶段：Proposer 选择一个提案编号 n，向多数 Acceptor 发送 Prepare 请求（编号 n）。Acceptor 收到后，如果 n 大于它已经见过的最小编号，则承诺不再接受编号小于 n 的提案，并返回当前已接受的最大编号提案（如果有）。
2. Accept 阶段：Proposer 收集到多数 Acceptor 的 Promise 响应后，从中选出编号最大的已接受值作为本次提案值（如果没有则使用自己的值），向这些 Acceptor 发送 Accept 请求（编号 n，值 v）。Acceptor 收到 Accept，只要编号不小于自己承诺过的最小编号，就接受该提案。

Paxos 保证了安全性：在任意时刻，最多只有一个值被多数派接受。

理解 Paxos 一个关键点：批准某个值需要多数派，但值确定的过程可能不止一轮。如果两个 Proposer 同时发起，会出现活锁——A 发出 Prepare(1)，B 发出 Prepare(2)，A 收到拒绝后重新 Prepare(3)，B 收到拒绝后 Prepare(4)，如此反复。

2.2 Raft 对 Paxos 的改进与工程化影响

Raft 本质上是 Multi-Paxos 的一个简化变体，目标是“可理解性优先”。Diego Ongaro 在 2014 年的博士论文中明确提出：Raft 的目的不是发明新算法，而是把 Paxos 的工程难点拆分成容易理解和实现的子问题。

Raft 的核心机制：

1. 领导选举（Leader Election）：集群中有一个 Leader，任期 term 单调递增。Follower 如果在选举超时时间内没有收到 Leader 的心跳，就转换为 Candidate，自增任期并请求投票，获得多数票后成为 Leader。
2. 日志复制（Log Replication）：Leader 将客户端请求包装成 Log Entry，复制到所有 Follower。Follower 写入本地日志后回复成功，Leader 收到多数派确认后提交该日志，并向客户端返回结果。
3. 安全性（Safety）：日志只能从 Leader 流向 Follower；Leader 只能提交自己任期内的日志；选举时 Candidate 必须包含所有已提交日志，通过比较日志的索引和任期来保证。

Raft 与 Paxos 的关键差异：