我说老李你说黑1. 为什么有人会把 SAGA 和 Paxos/Raft 放在一起聊
先讲个我最近遇到的事儿。
前阵子有个同事跑过来问我，说他在准备系统设计面试，看到别人整理的知识点里把 SAGA、Paxos、Raft 归到了同一个分类下，标题还写着“一致性算法”。他当时就懵了：SAGA 不是处理分布式事务的吗？Paxos 和 Raft 不是解决分布式共识的吗？这俩怎么混到一起去了？
其实有这个困惑很正常。这三样东西在分布式系统里都跟“一致”两个字有关——SAGA 保证的是业务数据最终一致，Paxos/Raft 保证的是多副本状态一致。但它们解决的问题层级完全不同，一个是偏业务层的方案，一个是偏基础设施层的协议。把这俩放在一起聊，本质上是想搞清楚：在一个复杂的分布式系统中，数据一致性问题到底分几个层面？每个层面该用什么工具？
这篇文章我就把我对这两个方向的完整理解拆开讲清楚。先从概念定位说起，再分别深入 SAGA 和 Paxos/Raft 的核心原理，最后聊一下它们在实际系统里怎么协同工作。不管你是刚接触分布式系统的新手，还是已经在业务里写过不少分布式代码的老手，这篇文章应该都能帮你把这两块知识的边界画得更清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先分清两个层面：共识算法和分布式事务各自管什么
2.1 一个经典的歪楼现场
我见过不少团队在讨论架构时，把“我们需要共识算法”和“我们需要分布式事务”这两句话混着说。比如有人提出订单服务要跨库操作，立刻就有同事说“那就上 Raft 呗”。这就是典型的两个层面没分清。
Raft 解决的是“多个节点对同一个值达成一致”，比如三个副本节点，要确认一条日志谁先谁后、提交到哪个位置。它工作在系统内部，是给基础设施用的。而 SAGA 解决的是“一个业务流程分散在多个服务里，怎么保证要么都成功要么都回滚”，它工作在业务逻辑层，是给应用开发用的。
这俩不但不是一个东西，连常见的组合场景都不一样。Raft 通常用在 etcd、Consul、TiKV 这类组件里做元数据同步和数据复制；SAGA 则用在订单、支付、库存这类跨服务的业务链路里。让 Raft 去处理业务流程补偿，或者让 SAGA 去同步多个副本的状态，那都是拿错了工具。
2.2 不同的一致性需求对应不同的一致性方案
要理解为什么需要两套方案，关键是要理解分布式系统里“一致”这件事有不同层级。
- 第一层：状态机一致性。一个系统有多个副本，客户端随便连哪个副本，读到的状态必须一样。这个层面追求的是强一致，解决方案就是 Paxos/Raft 这类的共识协议，把写操作复制到大多数节点上，保证对外只有一个统一的状态执行顺序。
- 第二层：事务一致性。一个业务流程跨越多个独立的数据库或服务，需要像一个本地事务那样，要么全部成功，要么全部回滚。这个层面由于数据分布在多个自治的存储节点上，没有办法用全局锁来实现严格的原子性，所以更多时候用 SAGA、TCC、本地消息表这类柔性事务方案来保证最终一致。
- 第三层：微服务之间最终一致。这是最上层，通常应用系统之间通过消息、事件、异步补偿来收敛状态。这个层面不追求严格意义上的事务，而是接受“短时间不一致、最终一致”的现实。
所以你看，Paxos/Raft 处于第一层，SAGA 处于第二层底层。它们不在一条赛道上，但很多网上文章喜欢把它们并列，是因为它们都属于“在分布式环境下解决一致性”这套方法论的一部分。
2.3 为什么不能用一个方案解决所有层面
有人可能会问：既然 Raft 能保证强一致，那我用 Raft 把多个数据库的状态同步起来，不就能实现跨库事务了吗？理论上可以，比如 Google Spanner 就是用类 Paxos 协议加原子钟来做全球跨数据中心强一致事务的。但问题是，这种方案工程成本极高，不是所有业务都需要。
大多数互联网业务场景并不需要跨库强一致。用户下单之后，订单列表和库存数量短暂不一致，完全可以通过补偿和重试来解决。真要为了一个库存扣减引入全局强一致基础设施，你得到的不是可靠，而是高延迟、高复杂度、高运维成本。SAGA 这类柔性方案的价值就在于：用一个相对简单的状态机加补偿逻辑，换取业务上的最终正确。
所以正确的思维方式是：先判断业务需要哪个层级的一致性，再选择对应的方案。底层系统用共识算法，业务链路用事务方案，二者不是替代关系。
3. SAGA 模式深入拆解：核心原理与你落地时会踩的坑
3.1 SAGA 到底在解决什么问题
SAGA 这个概念最早是 1987 年由 Hector Garcia-Molina 和 Kenneth Salem 在一篇数据库论文里提出的。它解决的核心问题是：当一个长事务拆分成多个本地事务时，如何保证整个流程在部分失败的情况下能够回滚到合理