微服务架构下的分布式事务实战：基于 Saga 模式的订单系统一致性设计与落地

订单系统几乎是分布式事务问题的“高发地带”。

一个用户下单，看起来只是点一下“提交订单”，但背后往往已经跨了多个服务：订单服务创建订单、库存服务扣减库存、支付服务发起扣款、营销服务冻结优惠券、积分服务累计积分、物流服务生成运单。只要其中一个步骤失败，就会出现“钱扣了但没下单”“库存减了但订单取消了”这类让业务和用户都崩溃的问题。

我自己在做订单域拆分时，最早也想过“能不能像单体里那样，一个数据库事务全包住？”后来很快发现，在微服务架构下这条路基本走不通：服务独立部署、数据库独立自治、调用链跨进程，传统本地事务的边界已经失效。这个时候，Saga 往往是更现实、也更常见的一种方案。

这篇文章不只讲概念，而是围绕一个订单系统，把 Saga 的一致性设计、代码实现、常见坑和优化点完整走一遍。

背景与问题

先看一个典型的下单链路：

订单服务创建订单，状态为 PENDING
库存服务冻结库存
支付服务完成扣款
订单服务改为 CONFIRMED
如果中途失败，需要按相反顺序补偿

问题在于：这些步骤不在一个数据库里，也不在一个进程里。

如果我们强行追求“强一致”：

用两阶段提交（2PC/XA）
所有服务参与全局锁定
所有资源必须支持 XA

那么通常会遇到几个现实问题：

性能差：全局事务拉长链路耗时
可用性差：协调器异常会影响整条业务
侵入性强：数据库、驱动、中间件都要配合
云原生环境不友好：异构存储、消息系统、NoSQL 很难统一纳入

而订单系统的很多业务，其实更适合另一种思路：

接受短暂的不一致，但通过状态机、补偿动作、幂等控制，最终达成业务一致。

这就是 Saga 的核心出发点。

方案对比与取舍分析

在落地前，先把几个常见方案摆在桌面上。

方案	一致性	性能	实现复杂度	适用场景
本地事务	强一致	高	低	单库单服务
2PC / XA	强一致	低	高	少量核心强一致场景
TCC	最终一致	中	很高	资金类、库存类强控制场景
Saga	最终一致	高	中	订单、履约、营销等长事务场景
事务消息 / Outbox	最终一致	高	中	事件驱动链路

为什么订单系统更常选 Saga

订单业务有几个典型特征：

跨服务步骤多
某些动作天然可补偿，比如取消订单、释放库存、退款
对“秒级内不一致”通常可以接受
追求高吞吐和高可用

所以 Saga 特别适合：

主链路快返回
失败靠补偿闭环
业务状态清晰可观测
适合和消息队列结合

但它也不是万能的。比如“银行转账到账户余额”这类场景，如果补偿成本极高或补偿不可靠，Saga 就不一定是首选。

核心原理

Saga 的基本思想可以概括成一句话：

把一个长事务拆成多个本地事务，每个本地事务成功后提交；如果后续某一步失败，则按已执行步骤的反向顺序执行补偿事务。

以订单场景为例：

正向事务：
- 创建订单
- 冻结库存
- 扣款
- 确认订单
补偿事务：
- 取消订单
- 释放库存
- 发起退款

编排式与协同式

Saga 常见有两种实现方式：

1. 编排式（Orchestration）

由一个 Saga Orchestrator 统一调度每一步。

优点：

流程集中、易观测
适合复杂业务编排
方便重试和补偿控制

缺点：

编排器会成为核心组件
设计不好会变成“上帝服务”

2. 协同式（Choreography）

各服务通过事件自行驱动下一步。

优点：

解耦更强
服务自治更自然

缺点：

调用链分散
排障困难
流程全貌不易看清

对于订单系统，我更建议优先从编排式起步。原因很简单：订单链路复杂、出错成本高、排障频率大，集中可视化比“纯优雅的自治”更重要。

订单 Saga 状态流转

stateDiagram-v2
    [*] --> PENDING
    PENDING --> INVENTORY_RESERVED: 库存冻结成功
    INVENTORY_RESERVED --> PAID: 支付成功
    PAID --> CONFIRMED: 订单确认
    INVENTORY_RESERVED --> CANCELLED: 支付失败/超时补偿
    PENDING --> CANCELLED: 库存冻结失败
    PAID --> REFUNDING: 确认失败需补偿
    REFUNDING --> CANCELLED: 退款完成
    CONFIRMED --> [*]
    CANCELLED --> [*]

执行与补偿顺序

sequenceDiagram
    participant User as 用户
    participant O as 订单服务
    participant S as Saga编排器
    participant I as 库存服务
    participant P as 支付服务

    User->>O: 提交订单
    O->>S: 启动Saga
    S->>O: 创建订单(PENDING)
    S->>I: 冻结库存
    I-->>S: 成功
    S->>P: 发起支付
    P-->>S: 失败
    S->>I: 补偿-释放库存
    S->>O: 补偿-取消订单
    S-->>User: 下单失败

一致性设计关键点

Saga 能不能在生产环境站得住，关键不在“会不会画流程图”，而在这几个细节上。

1. 每一步都必须是本地事务

例如：

创建订单：订单库本地事务提交
冻结库存：库存库本地事务提交
记录支付单：支付库本地事务提交

不要在服务内部再试图套跨库事务，那样会把简单问题重新复杂化。

2. 每个动作都要有可执行补偿

不是“理论可补偿”，而是系统里真能落库、真能重试、真能查状态。

例如：

冻结库存 -> 释放冻结库存
支付扣款 -> 发起退款
订单确认 -> 改为取消（若已发货则不能直接取消，需要升级为逆向售后流程）

这也提醒我们：补偿不是回滚。
很多业务动作一旦对外可见，就只能“反向修正”，不能“像数据库 rollback 一样完全撤销”。

3. 幂等是底线

在分布式环境下，重试是必然的，因此：

正向动作要幂等
补偿动作也要幂等
消息消费要幂等
HTTP/RPC 调用要支持请求唯一键

这点我踩过坑：库存释放接口第一次执行成功了，但编排器没收到响应，于是重试一次，结果把已卖库存又多释放了一次。最后不是事务问题，而是幂等没做好。

4. 需要持久化 Saga 状态

至少要记录：

saga_id
业务单号 order_id
当前步骤
执行状态
补偿状态
重试次数
错误原因
更新时间

没有这些信息，故障恢复时几乎无从下手。

实战设计：一个最小可运行的订单 Saga

下面用 Python 做一个可运行的编排式 Saga 示例。它不是生产级框架，但足够把设计思想跑通。

场景说明

我们模拟 3 个服务：

OrderService：创建/确认/取消订单
InventoryService：冻结/释放库存
PaymentService：扣款/退款
OrderSagaOrchestrator：负责编排和补偿

为了方便运行，示例使用内存存储，不依赖外部数据库。

实战代码（可运行）

from dataclasses import dataclass, field
from typing import Dict, List
import uuid


class SagaError(Exception):
    pass


@dataclass
class Order:
    order_id: str
    user_id: str
    product_id: str
    amount: int
    status: str = "PENDING"


class OrderService:
    def __init__(self):
        self.orders: Dict[str, Order] = {}

    def create_order(self, user_id: str, product_id: str, amount: int) -> str:
        order_id = str(uuid.uuid4())
        self.orders[order_id] = Order(order_id, user_id, product_id, amount, "PENDING")
        print(f"[Order] create order={order_id}, status=PENDING")
        return order_id

    def confirm_order(self, order_id: str):
        order = self.orders[order_id]
        if order.status == "CONFIRMED":
            print(f"[Order] confirm skipped, already CONFIRMED: {order_id}")
            return
        if order.status == "CANCELLED":
            raise SagaError(f"cannot confirm cancelled order: {order_id}")
        order.status = "CONFIRMED"
        print(f"[Order] confirm order={order_id}, status=CONFIRMED")

    def cancel_order(self, order_id: str):
        order = self.orders[order_id]
        if order.status == "CANCELLED":
            print(f"[Order] cancel skipped, already CANCELLED: {order_id}")
            return
        order.status = "CANCELLED"
        print(f"[Order] cancel order={order_id}, status=CANCELLED")


class InventoryService:
    def __init__(self):
        self.stock: Dict[str, int] = {"SKU-1": 10}
        self.reserved: Dict[str, int] = {}

    def reserve(self, order_id: str, product_id: str, count: int):
        if self.reserved.get(order_id):
            print(f"[Inventory] reserve skipped, already reserved for order={order_id}")
            return

        available = self.stock.get(product_id, 0)
        if available < count:
            raise SagaError(f"insufficient stock for product={product_id}")

        self.stock[product_id] -= count
        self.reserved[order_id] = count
        print(f"[Inventory] reserved {count} for order={order_id}, left={self.stock[product_id]}")

    def release(self, order_id: str, product_id: str):
        count = self.reserved.get(order_id, 0)
        if count == 0:
            print(f"[Inventory] release skipped, nothing reserved for order={order_id}")
            return

        self.stock[product_id] += count
        del self.reserved[order_id]
        print(f"[Inventory] released {count} for order={order_id}, left={self.stock[product_id]}")


class PaymentService:
    def __init__(self, should_fail: bool = False):
        self.paid_orders: Dict[str, int] = {}
        self.refunded_orders: Dict[str, int] = {}
        self.should_fail = should_fail

    def pay(self, order_id: str, amount: int):
        if order_id in self.paid_orders:
            print(f"[Payment] pay skipped, already paid order={order_id}")
            return

        if self.should_fail:
            raise SagaError(f"payment failed for order={order_id}")

        self.paid_orders[order_id] = amount
        print(f"[Payment] paid order={order_id}, amount={amount}")

    def refund(self, order_id: str):
        if order_id in self.refunded_orders:
            print(f"[Payment] refund skipped, already refunded order={order_id}")
            return

        amount = self.paid_orders.get(order_id)
        if amount is None:
            print(f"[Payment] refund skipped, no payment found for order={order_id}")
            return

        self.refunded_orders[order_id] = amount
        print(f"[Payment] refunded order={order_id}, amount={amount}")


@dataclass
class SagaLog:
    saga_id: str
    order_id: str = ""
    steps: List[str] = field(default_factory=list)
    status: str = "STARTED"
    error: str = ""


class OrderSagaOrchestrator:
    def __init__(self, order_service, inventory_service, payment_service):
        self.order_service = order_service
        self.inventory_service = inventory_service
        self.payment_service = payment_service
        self.logs: Dict[str, SagaLog] = {}

    def create_order(self, user_id: str, product_id: str, amount: int) -> str:
        saga_id = str(uuid.uuid4())
        log = SagaLog(saga_id=saga_id)
        self.logs[saga_id] = log

        order_id = None

        try:
            # Step 1: create order
            order_id = self.order_service.create_order(user_id, product_id, amount)
            log.order_id = order_id
            log.steps.append("CREATE_ORDER")

            # Step 2: reserve inventory
            self.inventory_service.reserve(order_id, product_id, 1)
            log.steps.append("RESERVE_INVENTORY")

            # Step 3: pay
            self.payment_service.pay(order_id, amount)
            log.steps.append("PAY")

            # Step 4: confirm order
            self.order_service.confirm_order(order_id)
            log.steps.append("CONFIRM_ORDER")

            log.status = "COMPLETED"
            print(f"[Saga] completed saga_id={saga_id}")
            return order_id

        except Exception as e:
            log.status = "FAILED"
            log.error = str(e)
            print(f"[Saga] failed saga_id={saga_id}, error={e}")

            self.compensate(log, product_id)
            raise

    def compensate(self, log: SagaLog, product_id: str):
        order_id = log.order_id
        print(f"[Saga] compensating saga_id={log.saga_id}, steps={log.steps}")

        # reverse order compensation
        if "PAY" in log.steps:
            self.payment_service.refund(order_id)

        if "RESERVE_INVENTORY" in log.steps:
            self.inventory_service.release(order_id, product_id)

        if "CREATE_ORDER" in log.steps:
            self.order_service.cancel_order(order_id)

        log.status = "COMPENSATED"
        print(f"[Saga] compensated saga_id={log.saga_id}")


if __name__ == "__main__":
    print("=== success case ===")
    order_service = OrderService()
    inventory_service = InventoryService()
    payment_service = PaymentService(should_fail=False)
    orchestrator = OrderSagaOrchestrator(order_service, inventory_service, payment_service)

    order_id = orchestrator.create_order("U-1", "SKU-1", 100)
    print("order result:", order_service.orders[order_id])

    print("\n=== failed case ===")
    order_service2 = OrderService()
    inventory_service2 = InventoryService()
    payment_service2 = PaymentService(should_fail=True)
    orchestrator2 = OrderSagaOrchestrator(order_service2, inventory_service2, payment_service2)

    try:
        orchestrator2.create_order("U-2", "SKU-1", 200)
    except Exception as e:
        print("caught:", e)

运行效果

成功场景会得到：

订单状态变为 CONFIRMED
库存被冻结后不释放
支付记录成功

失败场景会得到：

支付失败
自动触发库存释放
订单取消

从示例到生产：需要补齐什么

上面的代码只是教学版。真正上生产，至少还要补这几块：

1. Saga 日志持久化

可以设计一张表：

CREATE TABLE saga_instance (
    saga_id VARCHAR(64) PRIMARY KEY,
    order_id VARCHAR(64) NOT NULL,
    current_step VARCHAR(64) NOT NULL,
    status VARCHAR(32) NOT NULL,
    retry_count INT NOT NULL DEFAULT 0,
    error_message TEXT,
    created_at TIMESTAMP NOT NULL,
    updated_at TIMESTAMP NOT NULL
);

再加一张步骤执行表：

CREATE TABLE saga_step_log (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    saga_id VARCHAR(64) NOT NULL,
    step_name VARCHAR(64) NOT NULL,
    action_type VARCHAR(16) NOT NULL,
    status VARCHAR(32) NOT NULL,
    request_id VARCHAR(64) NOT NULL,
    error_message TEXT,
    created_at TIMESTAMP NOT NULL
);

这样做的价值很直接：

服务重启后能恢复
可以手动排查具体卡在哪一步
重试任务有依据
审计和追踪更完整

2. 与消息队列结合

编排器可以同步调用服务，也可以把每一步做成命令消息。

更常见的生产模式是：

编排器写 Saga 状态
通过 Outbox 写本地消息
异步投递到 MQ
下游消费后回传事件
编排器推进下一步

整体结构如下：

flowchart LR
    A[订单请求] --> B[Saga编排器]
    B --> C[(Saga状态表)]
    B --> D[(Outbox表)]
    D --> E[消息投递器]
    E --> F[库存服务]
    E --> G[支付服务]
    F --> H[库存结果事件]
    G --> I[支付结果事件]
    H --> B
    I --> B
    B --> J[订单状态更新]

这样可以避免“状态已更新但消息没发出去”的经典一致性问题。

3. 引入超时控制

订单 Saga 经常不是“立刻失败”，而是卡在中间。

比如：

支付网关长时间无响应
库存服务超时但实际已处理
MQ 消息积压

所以要为每一步设置：

请求超时
总超时
重试间隔
最大重试次数
超时后的补偿策略

常见坑与排查

这部分我建议认真看。因为 Saga 真正难的，不是“第一次写出来”，而是“线上出故障时能不能稳住”。

坑 1：补偿成功率被高估

很多人默认认为“失败了就补偿呗”。但补偿本身也是远程调用，也会失败。

例如：

支付退款接口也超时
库存释放时发现冻结记录已过期
订单取消时状态机不允许直接跳转

排查建议：

查 Saga 实例状态
查每一步执行日志
查补偿动作是否已发起
查下游服务幂等记录
必要时做人工兜底

坑 2：幂等键设计不统一

如果订单服务用 order_id 做幂等，支付服务用 payment_id，库存服务又用 request_id，一旦跨系统排查就很痛苦。

建议：

全链路统一 saga_id 和 order_id
每个动作再附带 step_request_id
所有日志都带上这些字段

坑 3：空补偿、悬挂问题

这是分布式事务里的老问题，在 Saga 中也常见。

空补偿：补偿先到了，但正向动作其实没成功
悬挂：补偿执行后，迟到的正向请求又执行了

应对方式：

正向和补偿都检查业务状态
用状态机约束非法跳转
对同一业务键加幂等与版本控制

坑 4：订单状态设计过于粗糙

如果订单只有 PENDING / SUCCESS / FAIL 三个状态，出了问题根本看不清。

更实用的设计通常包括：

PENDING
INVENTORY_RESERVED
PAYING
PAID
CONFIRMED
CANCELING
CANCELLED
REFUNDING
REFUNDED

状态多一点不是坏事，前提是状态机清晰。

坑 5：把 Saga 当成“最终都会一致”

不是所有不一致都会自动恢复。

如果没有这些机制，最终一致只是口号：

定时补偿任务
死信队列处理
人工干预后台
告警阈值
状态修复脚本

一套实用的排查路径

当线上出现“订单取消了但库存没回滚”这种问题时，可以按这个顺序查：

flowchart TD
    A[用户反馈订单异常] --> B[查订单状态]
    B --> C[查Saga实例状态]
    C --> D[查步骤执行日志]
    D --> E[查库存服务幂等/冻结记录]
    E --> F[查支付服务支付/退款记录]
    F --> G[判断是否自动重试]
    G --> H{是否可自动修复}
    H -- 是 --> I[触发重试/补偿]
    H -- 否 --> J[人工干预并记录根因]

这个流程看起来朴素，但真的很有用。线上处理最怕“每个人只看自己服务的一小段日志”。

安全/性能最佳实践

Saga 常被拿来讲一致性，但在生产中，安全和性能也非常关键。

安全最佳实践

1. 补偿接口必须鉴权

补偿动作本质上是高风险操作：

释放库存
取消订单
发起退款

这些接口不能因为“是内部服务调用”就裸奔。至少要有：

服务间身份认证
请求签名或 mTLS
调用来源白名单
审计日志

2. 防重放攻击

对于支付、退款这类动作，建议请求中带：

唯一请求号
时间戳
签名

并在服务端保存去重记录，避免消息重复或恶意重放。

3. 敏感数据最小化

Saga 日志里不应直接落：

完整银行卡号
用户敏感身份信息
支付凭证明文

日志要脱敏，审计字段和业务字段分开存储。

性能最佳实践

1. 缩短同步链路

不要把所有步骤都放在用户同步请求里等待完成。

比较合理的方式是：

前端下单后拿到 PENDING
后台异步推进 Saga
前端轮询或订阅订单状态变化

这样能显著降低主链路延迟。

2. 控制补偿风暴

如果某个下游服务故障，编排器可能会对大量订单同时触发重试和补偿，造成雪崩。

建议：

指数退避重试
补偿并发限流
熔断下游故障服务
对失败订单分批处理

3. 热点商品库存单独治理

高并发商品下，库存冻结很容易成为瓶颈。

可以考虑：

预扣减库存池
Redis + 异步落库
按商品分片
热点 SKU 隔离队列

但前提是：你要非常清楚一致性边界，否则性能优化很可能引入更复杂的库存错账。

容量估算与落地建议

在架构设计时，别只盯着功能流程，还要估算系统会承受多大压力。

一个简单估算模型

假设：

峰值每秒下单 2000 单
每单 Saga 平均 4 个步骤
每个步骤平均产生 2 条日志
保留 30 天

那么仅步骤日志写入量约为：

2000 * 4 * 2 = 16000 条/秒

30 天量级会非常可观，因此要提前考虑：

Saga 日志分库分表
冷热数据分层
审计日志和在线状态分离
查询索引设计

我更推荐的落地节奏

如果你们团队是第一次做 Saga，不要一上来就“平台化大一统”。比较稳的方式是：

先选一个核心链路试点
比如“下单-库存-支付”三段
先做编排式
流程更清楚，排障成本更低
先把幂等、日志、重试、补偿做扎实
不要急着追求优雅抽象
跑出线上经验后再沉淀框架
否则很容易造出一个好看但不好用的 Saga 平台

总结

在微服务架构下，订单系统的分布式事务问题几乎绕不过去。而 Saga 之所以实用，不是因为它“理论上高级”，而是因为它承认现实：

跨服务事务很难做到强一致
失败和重试是常态
补偿比回滚更符合业务本质
最终一致比伪强一致更容易落地

落地 Saga 时，我建议你重点抓住这几件事：

把业务拆成清晰的本地事务步骤
为每一步设计真实可执行的补偿动作
全链路做好幂等、状态机和日志持久化
用编排式先跑通，再考虑事件化扩展
准备好超时、重试、死信和人工兜底机制

最后给一个边界判断：

如果你的场景要求绝对强一致、补偿不可接受，Saga 不是最佳方案。
如果你的场景是订单、履约、营销、积分这类长事务，且允许短暂不一致，那么 Saga 往往是最平衡的选择。

真正靠谱的分布式事务设计，从来不是“选了某个模式就结束”，而是把失败当成系统的一部分去设计。订单系统能否稳定，很多时候就取决于你对这些失败细节处理得有多认真。