# 分布式事务正常跑得飞快，凌晨出错谁来还债？

> 正常链路只证明快乐路径，异常链路才是账单。

```text
[读者] 写过订单、支付、通知串行链路的后端与架构同学
[痛点] 正常路径跑得顺，异常路径一上来就靠人肉对账
[现在读] 一次超时或一次重复回调，就能把账和信任同时打穿
[读完] 能画出失败矩阵、配好幂等键与补偿状态机，按终态验收
```

```text
[旧方案] 三步调用都返回成功，就当事务已经完成
    |
    v
[新需求] 超时、重复、部分成功、补偿失败都要有出口
    |
    v
[冲突] 跨服务没有全局原子性，任何一步都可能停在中间态
    |
    v
[后果] 支付成功订单未知，凌晨靠人肉对账还债
```

我是老李，这些年主要在做交易链路和中间件。见过最多的不是写不出代码，而是写完了却说不清“这笔单到底算不算完成”。

分布式事务的复杂度，主要不在正常路径上。正常路径是产品经理画的流程图，异常路径才是运维半夜接到的电话。

一个系统如果只被验证过“全部成功”，那它其实没有被验证过。上线验收必须覆盖每一条失败出口，否则故障时间会替你把剩下的九成补上。

串行调用每一步都返回成功，事务就算完成了吗？

跨服务没有全局原子性，验收到底该盯哪一步？

补偿代码写了几百行，为什么凌晨还是要人肉救火？

# 01、故事

一条典型链路：订单服务减库存、支付服务接第三方回调、通知服务发短信，三个服务各管各的本地事务，中间靠消息串起来。平时跑得很快，压测报告也很漂亮。任务是让“用户付款后订单一定变成已支付、库存一定扣对、通知一定发出”。

变化来得没有预告。促销开始后，第三方支付的回调开始抖动：有时慢到十几秒，有时干脆重复推两次。用户等不及点了刷新，链路里就多出一条订单。

这时候团队才发现，过去所有的验证都发生在这条链路的快乐路径上。超时、重复、部分成功、补偿失败这四件事，一件都没有被设计过。

代码没写错，验收标准写错了。

> 链路跑得快
> 异常无人管
> 顺境不算数
> 逆境见真功

# 02、问题

旧方案失效得很安静：把“每一步都返回成功”当成事务完成。业务影响是用户投诉“钱扣了订单没了”，客服靠导出表格手工核账。技术表现是订单状态卡在初始态、事件表里没有对应记录、同一个业务键出现两条处理记录、补偿动作被执行了两次。

可验证的完成标准要换掉：步骤级失败矩阵的每一格都有对应出口；全链路业务幂等键有唯一约束且真实生效；补偿状态机有明确终态且不可逆；对账差值可被解释、可被归零。

成功返回只是其中一格，不是全部。

> 会成功不算赢
> 会失败才算稳
> 标准若模糊
> 上线必翻车

# 03、原理

反直觉判断：分布式事务的“完成”不是一个瞬间，而是一组可收敛的状态集合。只要每种中间态都有归宿，它就算设计对了。

Saga 把长事务拆成若干本地事务，每一步配一个补偿动作，协调方式分事件编排与编排器两种。它换来原子性，但缺隔离性，中间态对外可见，需要语义锁一类手段去挡住误读（参见 [Saga 模式](https://microservices.io/patterns/data/saga.html)）。

Transactional Outbox 把业务变更和事件写在同一个本地事务里，再由中继发布出去，解决“改了库但消息没发”的裂缝。代价是投递通常至少一次，消费端必须幂等（参见 [Transactional Outbox](https://microservices.io/patterns/data/transactional-outbox.html)）。

补偿事务撤销的是已发生步骤的净效果，不是数据库回滚。有些步骤天生不可补偿，比如已发货、已发短信，所以顺序本身要设计（参见 [Compensating Transaction](https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction)）。

> 完成非一瞬
> 收敛才算数
> 补偿非回滚
> 幂等是地基

# 04、架构

```text
[输入] 支付回调 / 下单请求（可能超时、可能重复）
    |
    v
[模块] 幂等层 + 业务服务 + Outbox 中继 + Saga 编排器 + 死信队列
    |
    v
[数据/状态] 幂等键表、outbox 表、补偿状态机表、三方回执
    |
    v
[处理] 本地事务推进状态 → 同事务写事件 → 中继发布 → 失败进补偿或死信
    |
    v
[输出] 明确终态 + 对账结果 + 人工工单
```

边界：这套结构只解决最终一致性，不提供跨服务的强一致读；补偿要求步骤可逆或可前置排序。收益是每条失败出口都有归宿，代价是多一张表、多一个终态、多一套值守流程。适用条件是业务能接受短暂不一致，且每一步的失败都可描述。

> 有图才有界
> 有界才敢放
> 状态先想全
> 代码才不慌

# 05、实战一次

环境：JDK 21 与 PostgreSQL 14 以上，Python 侧使用 psycopg 3（版本以官方文档为准）。依赖：一个消息客户端对象 `mq`。配置：数据源指向业务库，中继独立进程运行。

```sql
create table orders (
  order_id varchar(64) primary key,
  status   varchar(16) not null default 'INIT'
);

create table pay_idempotent (
  biz_key  varchar(128) primary key,
  order_id varchar(64) not null
);

create table outbox (
  id          bigserial primary key,
  aggregate_id varchar(64) not null,
  event_type   varchar(64) not null,
  payload      jsonb not null,
  status       varchar(16) not null default 'NEW',
  retry_count  int not null default 0
);
```

```python
import json

def pay_success(conn, biz_key, order_id, amount):
    with conn.transaction():
        cur = conn.execute(
            "insert into pay_idempotent(biz_key, order_id) values (%s, %s) "
            "on conflict do nothing returning biz_key", (biz_key, order_id))
        if cur.fetchone() is None:
            return "DUPLICATE"
        n = conn.execute(
            "update orders set status = 'PAID' where order_id = %s and status = 'INIT'",
            (order_id,)).rowcount
        if n == 0:
            raise RuntimeError("状态不允许推进: " + order_id)
        payload = json.dumps({"orderId": order_id, "amount": str(amount)})
        conn.execute(
            "insert into outbox(aggregate_id, event_type, payload) values (%s, %s, %s::jsonb)",
            (order_id, "OrderPaid", payload))
        return "OK"

def relay_once(conn, max_retry=5):
    rows = conn.execute(
        "select id, payload from outbox where status = 'NEW' order by id limit 100").fetchall()
    for out_id, payload in rows:
        try:
            mq.publish("order-paid", payload)
            conn.execute("update outbox set status = 'SENT' where id = %s", (out_id,))
        except Exception:
            conn.execute(
                "update outbox set retry_count = retry_count + 1, "
                "status = case when retry_count + 1 >= %s then 'DEAD' else 'NEW' end where id = %s",
                (max_retry, out_id))
    conn.commit()
```

启动：先起业务服务，再单独起中继进程。请求：`curl -X POST /pay/callback -d '{"bizKey":"pay-1001","orderId":"o-1","amount":"9.90"}'`。验证：同一个 bizKey 连发两次，第一次返回 OK，第二次返回 DUPLICATE；再查 outbox 状态与订单状态。

未在当前环境实测，以下为预期结果。示例输出：

第一次回调：pay_idempotent 新增 1 行，orders.status 从 INIT 变为 PAID，outbox 新增 1 行 NEW。重复回调：pay_idempotent 不变，orders.status 仍为 PAID，outbox 不再新增。

V1 到这里只跑通了快乐路径，超时与死信还没处理，问题留给后面。

> 先跑通一条
> 再留一个坑
> 小步能验证
> 大步不失控

# 06、排查

现象一：支付回调成功后订单仍停在待支付，用户重复下单。怀疑是消息丢了。检查 outbox 表与中继日志，证据是 outbox 里有 NEW 记录长期不变 SENT，消费端日志查不到该 orderId。根因是早期版本先发消息后提交本地事务，事务回滚后消息已经飞出去；或者中继根本没启动。修复是改成同库同事务写 outbox，中继独立轮询，投递至少一次，消费端用业务键去重。

现象二：同一订单出现两笔退款。怀疑退款接口不稳。检查补偿日志与补偿幂等键，证据是同一条补偿动作有两条记录且 biz_key 为空。根因是补偿动作没配幂等键，重试一次就多一次副作用。修复是补偿同样带唯一业务键，重复执行直接返回首次结果。

**错误尝试：** 把超时从 3 秒调到 30 秒、重试从 3 次调到 10 次。为什么错：超时只是把失败从“早失败”推迟成“晚失败”，而重复次数被放大，副作用成倍增长；重试只对临时性失败有效，对“状态不允许推进”这类确定性失败完全无效，反而拖长故障窗口。

> 现象会骗人
> 证据不会
> 猜一次错一次
> 查一次准一次

# 07、优化

按证据形成 V2。第一处：业务与事件同事务写 outbox，中继独立发布。原因是消除“改了库没发消息”，新行为是事件不丢但可能重复，验证方式是杀掉中继再启动，观察 outbox 从 NEW 收敛到 SENT。

第二处：全链路统一业务幂等键，覆盖支付回调、消息消费与补偿动作。原因是重复不可避免，新行为是重复执行收敛到首次结果，验证方式是对同一 bizKey 连续投递并检查唯一约束冲突次数。

第三处：Saga 状态机显式终态，成功、已补偿、待人工三态互斥且不可逆，重试限次并配指数退避，超限进死信队列。原因是让“停不下来”的流程有一个确定的归宿。

第四处：每日对账任务比对三方回执与本地状态，差值生成人工工单。原因是不可补偿的步骤必须有人接住。

> 根因定方向
> 改动有依据
> 验证不虚构
> 优化才站得住

# 08、演进

```text
[同一输入] 支付回调超时且被重复投递
    |
    +--[V1] 以返回码判定完成 / 代价：重复入账、订单未知、人肉对账
    |
    +--[V2] 幂等键 + Outbox + 补偿状态机 + 死信对账
    |        / 代价：多一张表、多一个终态、多一套值守流程
    |
[Trade-off]
得到：异常路径有出口，验收有终态
失去：单次调用时延与实现复杂度
适用边界：最终一致性可接受、步骤可补偿或可前置排序的业务
```

比较维度：正确性上 V2 覆盖了中间态；稳定性上 V2 不再依赖“不超时”这个假设；复杂度上 V2 明显更高，需要中继与对账两个常驻组件；成本上是存储与运维投入；适用范围上 V2 适合交易类链路，不适合要求强一致读的场景。遗留问题是中间态对外可见，需要语义锁或状态前置校验继续补。

> 旧路快而脆
> 新路稳而重
> 取舍写明白
> 演进才有底

# 09、洞见

## 9.1 完成标准要从返回码换成失败矩阵

系统能不能上，不看成功那一格，看剩下每一格有没有名字。步骤级失败矩阵画不出来，说明边界还没想清楚，代码写得再漂亮也只是在赌。

## 9.2 幂等不是优化项，是重试的前提

反直觉判断：幂等键看起来是防止重复的补丁，实际上它是让“重试”这件事变得可用的地基。没有幂等，任何一次超时重试都是一次风险放大器；有了幂等，重试才从赌博变成工程手段。

## 9.3 补偿不是无条件回滚

反直觉判断：补偿写得越多不代表越安全，不可补偿的步骤才是设计核心。已发货、已发短信这些动作撤不回来，正确的做法是把它们排到最后，而不是多写几行回滚代码。

## 9.4 人工不是兜底，是系统的一部分

死信队列、对账任务、人工工单，如果只在事故时临时拉群，那它就不是设计。把它们当成正式组件，配上状态与SLA，才能让“凌晨谁来还债”这个问题有确定答案。

> 洞见不靠猜
> 全靠证据撑
> 反直觉之处
> 常藏真功夫

# 10、系统落地

原来有什么：一条能跑通的成功链路，和一堆事后补的 if 判断。本篇新增什么：失败矩阵、幂等键表、outbox 表、显式补偿状态机、死信与对账。现在能做什么：任何一次超时或重复投递，都能被识别并收敛到确定终态，不再依赖人肉记忆。还缺什么：跨服务的中间态对外可见问题、对账差异的自动归因、演练常态化。下一步演进：把故障演练做成例行任务，定期杀掉中继、模拟重复投递与三方超时，把每一条失败出口都真跑一遍。

> 原来只有路
> 现在多了闸
> 闸门认状态
> 落地才算数

# 11、小结

```text
Q1 → 不是。串行成功只证明快乐路径可跑，完成标准是每条失败出口都有归宿
Q2 → 盯停在中间态的那一步：支付成功但订单未知，才是验收重点
Q3 → 因为补偿没做成状态机、缺幂等键、缺死信与对账，人工成了唯一出口
状态 → 失败矩阵 + 幂等键 + Outbox/Saga + 死信对账，交付一条能收敛的链路
```

> 三问皆有答
> 一链可验收
> 不怕夜里有事
> 只怕没人兜底

# 12、作业

## 12.1 理解题：为什么“支付成功但订单未知”比“全部报错”更危险？

参考答案：全部报错是显性失败，用户与系统都能立刻感知并重试；部分成功是隐性失败，账面上看起来一切正常，实际状态停在中间态，用户可能已付款而订单不存在，只能靠对账事后发现。

## 12.2 实战题：给补偿动作加幂等，最小改动是什么？

参考答案：为每条补偿动作生成唯一业务键，落库加唯一约束，执行前先插入该键，冲突即代表已执行过，直接返回首次结果；同时给补偿状态加终态约束，禁止从已完成回退。

## 12.3 排障题：outbox 中大量记录长期为 NEW，怎么定位？

参考答案：先看中继进程是否存活与轮询间隔是否生效，再看是否有异常被吞掉导致状态未更新，最后检查发送端是否在事务提交前就发布或连接是否被错误关闭。逐层排除，不要先改重试次数。

## 12.4 架构判断题：一个步骤已发货、要求强一致读的业务，是否适合直接套这套方案？

参考答案：不适合。已发货属于不可补偿步骤，强一致读又超出最终一致性边界。应改为把发货前置到可取消阶段之后，或用预留与确认模型隔离不可逆动作，并把一致性要求拆到局部。

> 会做不算懂
> 会判才算通
> 四题练一遍
> 手上才有活

# 13、思考

分布式事务的复杂度几乎全部来自异常路径。设计时把时间花在正常流程上，上线后就得把时间花在异常流程上，区别只是前者在会议室，后者在凌晨。

真正的分水岭不是用不用 Saga 或 Outbox，而是你有没有把“完成”从一个返回码，改造成一组有终态、可对账、可收敛的状态。补偿有边界，重试有前提，人工有流程，这三件事说清楚了，链路才敢上线。

> 顺境不验收
> 逆境必还债
> 先画失败图
> 再谈高可用

我是老李，这些年主要在做交易链路和中间件。见过最多的不是写不出代码，而是写完了却说不清“这笔单到底算不算完成”。

技术思考问题36：分布式事务成功了，失败谁兜底？

正常链路跑得飞快，异常链路才是账单。跨服务没有全局原子性时，验收要盯住超时、重复、部分成功与补偿失败。本文给出失败矩阵、幂等键、Outbox 与补偿状态机的可落

架构师

人工智能

分布式事务的复杂度全在异常路径：支付成功但订单未知、重复回调、补偿无终态，才是真正账单。用幂等键+Outbox+Saga状态机，让每条失败出口有归宿，以失败矩阵验收，才不靠人肉救火。

代码解释

中间件

数据库

短信

Python

JSON

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

技术思考问题36：分布式事务成功了，失败谁兜底？-腾讯云开发者社区-腾讯云

技术思考问题36：分布式事务成功了，失败谁兜底？

技术思考问题36：分布式事务成功了，失败谁兜底？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐