2.1 分布式事务是问题域#

本地事务在一个数据库边界内提供原子性、一致性、隔离性和持久性。分布式事务面对的是跨服务、跨数据库或跨机构的一组相关操作，需要处理网络延迟、进程故障、重复请求和部分成功。

分布式事务不等于强一致事务。它既包括 2PC 这类刚性事务，也包括 TCC、Saga 和可靠消息等柔性事务方案；状态机是常与这些方案配套的运行机制，不是独立的事务协议。

2.2 一致性是目标#

强一致主要描述读写对已提交事实的可见性和顺序；参与者像一个整体一样提交或失败，属于原子性和原子提交协议的要求。核心账务内部的短事务、同库的余额和分录更新，需要在同一个本地事务中同时守住原子性与一致性；这不是对跨机构链路的绝对承诺。

最终一致允许系统短时间处于中间状态，但要求在参与者最终可访问、重试链路仍可运行、补偿规则已经定义的前提下，进入约定终态，并且能够验证和修复。订单通知、积分、商户回调和跨机构结果可以采用这个目标；如果外部系统永久不可用或没有可执行的补偿，系统只能进入挂账或人工接管，不能宣称自动最终一致。

BASE 用三个词描述这类取舍：基本可用、软状态和最终一致。它不是“资金可以长期不一致”，而是把等待和恢复交给状态机、重试、补偿与对账。

2.3 手段位于不同层#

1
分布式事务：要解决的问题
2
├── 一致性目标：强一致 / 最终一致
3
├── 协调模式：2PC / XA / 3PC / TCC / Saga
4
├── 消息传播：Outbox / 事务消息 / 最大努力通知
5
└── 运行闭环：幂等 / 状态机 / 重试 / 补偿 / 对账

这里的术语不能互相替代。Outbox 解决业务提交后发送意图不能丢，不能替消费者做幂等；TCC 协调资源预留和确认，不能替业务判断退款金额；定时任务推进状态，不能让两个数据库原子提交；对账验证结果，也不等于前面的操作自动正确。

2.4 投递语义为什么会带来重复#

投递语义描述消息或请求在发送方与接收方之间如何到达，不直接保证消费者的业务副作用只执行一次。本文把至少一次投递作为金融链路的传输层基线，再用业务幂等约束把重复调用收敛成同一个结果。

假设消费者已经在数据库里完成记账，但进程在确认消息前崩溃。消息系统看不到消费确认，会重新投递；如果消费者先确认、再提交本地事务，进程也可能在两步之间崩溃，造成消息丢失。把确认放在本地事务提交之后，可以避免提前丢消息，但必须接受“业务已提交、确认未送达”时的重复投递。

端到端调用存在不可判定的超时窗口：调用方无法仅凭连接断开分辨“对方没有收到”和“对方已经完成但响应丢了”。消息系统可以在限定边界内提供事务生产或幂等生产能力，但这不自动覆盖消费者数据库、支付渠道和跨机构账务。所谓业务上的“有效一次”，依赖稳定业务键、数据库唯一约束、合法状态转移和后续对账，而不是要求网络只传输一次。

2.5 幂等键、去重记录与状态机各自守什么#

幂等键标识业务操作，例如支付请求号或退款单号；消息 ID 只标识一次传输，重新包装同一笔退款时可能变化。消费者应把业务键写入具有唯一约束的业务记录，或与业务变更一起写入 Inbox/去重表。

Inbox 与业务效果要处在同一个本地事务中：若先标记“已消费”再记账，事务外的崩溃会让消息重投时被错误跳过；若先记账再单独标记，崩溃会导致重复记账。把两者放在同一事务后，重复消息命中唯一键，消费者读取既有结果并返回。

去重只回答“这笔业务是否已经处理”，状态机还要回答“现在是否允许处理”。退款操作还需检查原交易状态、累计退款金额和版本顺序；因此幂等键不能取代业务规则，去重表也不能取代状态机。

4.1 刚性事务：2PC、XA 与 3PC#

2PC 把提交分为准备和提交两个阶段。准备阶段中，协调者向参与者询问是否可以提交；参与者执行本地变更但不提交，把恢复所需的日志持久化后回复 YES。协调者只有在所有参与者都准备成功后，才写入并广播全局提交决定；任意参与者拒绝或准备超时，则广播回滚决定。

2PC 的关键代价是参与者在准备后必须保留锁和临时资源，直到知道全局决定。故障窗口可以这样看：

因此，2PC 的目标是原子提交协议，不是“网络断开后仍然自动正确”的保证。参与者需要持久化 prepare/commit 状态，协调者需要可靠日志和恢复流程；即使如此，长事务锁、协调者恢复和跨机构资源不可锁定仍然限制了它在金融外部链路中的适用范围。

以“订单状态和内部账务分录必须同时提交”为例，2PC 的正常路径如下。这里的两个参与者都在本组织可控制的数据库内，协调器可以读取事务日志并恢复决定：

如果账务库在 Prepare 阶段返回 NO，协调器会让订单库回滚；如果协调器在发出 Commit 后宕机，订单库和账务库可能暂时看见不同状态，恢复流程必须从协调器日志重建全局决定。这个例子说明了 2PC 的适用边界：它适合短事务和可控参与者，不适合把外部支付渠道也锁进同一条事务。

XA 是数据库和事务协调器之间的标准接口，适合边界明确、执行时间较短的内部事务。把 XA 跨到外部支付渠道或跨机构网络，会遇到资源不可锁定、接口不支持事务协议和故障恢复边界不清等问题。

3PC 在 2PC 中增加 CanCommit、PreCommit 和 DoCommit 阶段，并给协调者和参与者加入超时行为，试图减少协调者故障带来的无限等待。超时只能依据协议状态做推断；网络分区或参与者状态不一致时，仍可能出现不同参与者做出不同决定。金融系统更常见的做法是缩小强一致边界，再用柔性方案处理跨服务部分。

4.2 最终一致性方案地图#

下表把跨服务协调、消息传播和运行补偿放在同一张地图中，但它们不是同一种协议：TCC 和 Saga 负责业务协调，Outbox 和事务消息负责可靠传播，状态机和定时任务负责持续推进与修复。

5.1 TCC：先预留，再确认或取消#

TCC 把一个操作拆成三个接口：

1
Try：冻结金额或预占额度
2
Confirm：确认使用预留资源
3
Cancel：释放预留资源

以转账为例，Try 可以冻结付款账户的金额，同时预留收款侧额度；所有参与者的 Try 成功后，协调器调用 Confirm；任意一步无法预留，则调用 Cancel 释放已经占用的资源。

TCC 的关键不是接口数量，而是每个阶段都要面对重复、乱序和超时：

• Try、Confirm 和 Cancel 都必须幂等。
• Cancel 可能在 Try 没有到达时先执行，这叫空回滚。
• Cancel 先完成后，迟到的 Try 不能再创建资源占用，这叫悬挂。
• Confirm 或 Cancel 失败时，需要重试、告警和人工接管。

空回滚和悬挂来自同一个竞态：协调器调用 Try 后等待超时，可能发起 Cancel；网络中延迟的 Try 随后才到参与者。如果参与者把“没有 Try 记录”简单当成取消成功，却没有留下已取消标记，迟到的 Try 就会创建一份本应释放的冻结。

参与者需要按全局事务号或业务操作号持久化分支状态。Cancel 找不到 Try 记录时写入取消墓碑并幂等返回；后到的 Try 检查墓碑后拒绝预留。墓碑的保留期要覆盖最大网络延迟、协调器重试窗口和人工恢复窗口，不能在任务成功后立即清理。Confirm 和 Cancel 也要用条件状态转换保证只能从允许的分支状态执行，重复请求返回已有结果。

1
协调器                 资源参与者
2
  |---- Try ------------->|  请求在网络中延迟
3
  |  超时，发起 Cancel     |
4
  |---- Cancel ---------->|  未见 Try，记录已取消标记
5
  |                       |
6
  |---- 延迟的 Try ------>|  检查标记，拒绝创建冻结

TCC 适合能明确表达“预留”和“释放”的资源。它并没有消除中间状态：冻结会占用可用额度，协调器故障会延长冻结时间，参与者必须监控长时间停留在 TRY 的分支并提供可审计的恢复入口。外部渠道如果只提供一次扣款接口，不能仅靠 TCC 框架把它变成可取消操作。

以转账 100 元为例，付款账户先冻结 100 元，收款账户预留入账额度；两边都 Try 成功后才 Confirm。如果收款账户额度不足，付款账户收到 Cancel，解冻 100 元。与 2PC 相比，TCC 把“锁住数据库资源”改成业务层的冻结记录，因此其他查询可以看到“冻结中”，但不能把这笔钱再次使用。

5.2 Saga：多个本地事务加补偿动作#

Saga 把长流程拆成多个已经提交的本地事务，每一步都有对应补偿动作。比如放款流程可以依次完成审批、额度占用、放款指令和通知；其中一步失败时，协调器按业务规则执行已完成步骤的补偿。

Saga 不需要在整个流程中持有资源锁，适合能够接受中间状态的长流程；补偿也不一定等价于数据库回滚。补偿可能产生退款、冲正或新的会计分录，因此每个正向动作和补偿动作都需要稳定业务键、幂等约束、审计记录和重试边界。

Saga 可以由中央协调器按命令推进，也可以由各服务通过事件编排。步骤少时事件编排较直观，步骤和分支变多后，中央协调器更容易追踪流程和执行补偿；选型应以可观测、可恢复和可测试为准。

Saga 常见的恢复方向有两种。向后恢复在某一步失败后，按相反顺序执行已完成步骤的补偿；向前恢复则保留已完成步骤，修复故障后继续重试后续动作，适用于必须完成且重试最终可能成功的流程。两种方向都需要明确业务终态，不能把补偿调用返回成功等同于原业务已经恢复。

Saga 没有 TCC 的预留阶段，也就没有跨步骤的隔离保证。两个并发流程可能同时读取同一额度并各自继续；要通过本地条件更新、资源预占、版本检查或业务串行化防止写偏差。补偿动作也可能失败或只部分抵消原动作，例如已发出的通知不能撤回，已完成的外部转账需要追加反向交易。因此补偿记录应关联原步骤，支持重试与人工处置，不覆盖历史事实。

以贷款放款为例，审批、额度占用、放款指令和通知可以分别提交本地事务。放款指令失败时，Saga 不会回滚已经提交的审批记录，而是执行“释放额度”或“撤销放款申请”等补偿动作：

如果银行已经受理放款指令但响应超时，系统不能直接执行释放额度；应先查询银行结果，把“已受理但本地未知”保留为中间态。这个例子体现了 Saga 的边界：补偿动作改变业务事实，不会让外部世界回到事务开始前的瞬间。

6.1 Outbox：把业务事实和发送意图绑在一个本地事务中#

本地消息表和 Outbox 属于同一类模式：应用在业务库中维护一张与业务事务同库的待发送事件表，再由转发器异步投递。“本地消息表”更强调用业务表和消息表配合轮询，Outbox 更强调事件是业务事务提交后的外发记录；两者的可靠性边界相同，都无法消除重复投递。

一条典型流程如下：

1. 服务在本地事务中写入业务事实和 Outbox 事件。
2. 转发器扫描未发送事件，把事件投递到消息系统。
3. 消费者用业务幂等键执行业务事务。
4. 消费成功后，消费者确认消息或记录消费状态。
5. 发送失败、消费失败或超过重试上限的事件进入退避重试、死信或人工处理。

Outbox 解决的是“业务已经提交，但发送意图没有保存”的问题。转发器可能已经发送成功，却在标记事件已发送之前崩溃，因此 Outbox 本身仍然是至少一次投递，下游仍然必须幂等。

两个崩溃窗口决定了它为何需要和消费者幂等配套：

Outbox 表还需要可运维的生命周期：至少保存事件主键、聚合业务键、事件类型、版本、创建时间、发送状态、重试时间和最后错误。转发器用有界批次领取记录，避免多个实例长期占有或扫描同一批；已发送记录的归档与清理必须晚于审计、重放和排障所需的保留期。

对这笔 100 元支付，支付服务可以在同一个本地事务中写入支付单和 PaymentSucceeded 事件。转发器即使在发送成功后宕机，也只会让同一事件再次进入队列；账务消费者用支付流水号做唯一键，第一次写入 100 元分录，第二次读取已有结果后直接确认消息。

6.2 事务消息：缩小本地事务与消息之间的空窗#

事务消息一般通过预提交、执行本地事务、确认投递和回查等步骤，协调本地事务结果与消息状态。它适合已有可靠消息基础设施的异步场景，但保证范围必须看清：消息系统的事务能力不自动覆盖消费者数据库，更不覆盖外部渠道。

抽象流程可以画成这样，具体消息系统对“半消息”和“回查”的命名会不同：

如果生产者在本地事务完成后宕机，消息系统只能通过回查或人工接口判断该消息应提交还是回滚；如果消费者提交业务事务后没有确认，消息仍可能重复投递。因此事务消息缩小的是“本地事务与消息之间”的空窗，不是全链路的恰好一次。

看到 Exactly-once 时，继续确认它指的是传输次数、生产端写入，还是包括消费者业务效果。金融系统更常见的组合是：持久化的至少一次投递，加上消费者幂等、合法状态转移和对账修复。

6.3 最大努力通知：外围链路的送达策略#

商户通知、第三方回调和短信邮件不适合阻塞核心账务。通知服务可以按退避策略重试，超过上限后进入差错池，并提供主动查询或重新发送入口。

最大努力通知不能替代外部渠道的主动查询和账单对账。回调丢失时，系统必须能够从渠道查询或账单中重新获得外部事实。

7.1 用显式状态表示事实边界#

支付、退款和转账至少要区分待处理、处理中、成功、明确失败和未知结果：

1
PENDING
2
  ↓
3
PROCESSING
4
  ├── SUCCESS
5
  ├── FAILED
6
  └── UNKNOWN
7
          ↓
8
    查询 / 重试 / 对账 / 人工接管

UNKNOWN 不是 FAILED 的别名。调用方超时只说明没有拿到结果，渠道可能已经完成扣款。把未知状态直接改成失败，会让下一次补偿重新发起不可逆操作，形成重复扣款风险。

状态机不能只列出状态名，还要写出事件、前置条件和副作用。以支付单为例，至少需要约束以下转移：

CHANNEL_SUCCESS 这类中间状态用于保存外部事实与本地账务之间的间隔。若把渠道成功直接写成 SUCCESS，订单、积分和通知可能先于账务完成，查询方也无法区分“渠道已扣款但本地未记账”和“钱已经完整入账”。状态转换应带版本或条件，更新影响行数为零时读取当前状态并判断它是否已经由另一条路径完成。

状态机图可以进一步表达“查询结果”和“补偿结果”如何回到同一条路径：

SUSPENSE 表示事实已经发生但本地账务尚未完成，REVERSED 表示系统通过反向分录完成修复。它们不是为了让状态枚举更丰富，而是为了让查询、重试、对账和人工处理知道下一步应该依据哪份证据行动。

7.2 定时任务的完整流程#

1. 本地事务写入业务记录和待处理意图，状态设为 PENDING，同时保存业务幂等键、重试次数和 next_retry_at。
2. 任务按状态和时间窗口批量领取到期记录，通过有期限的租约或条件更新标记为 PROCESSING，并保存领取者和租约到期时间。
3. 任务调用下游接口，携带同一个业务幂等键；下游成功后，本地以状态条件更新为 SUCCESS。
4. 明确业务拒绝进入 FAILED；连接超时或无响应进入 UNKNOWN，后续先查询相同业务键的结果，不创建新的资金操作。
5. 进程若在领取后崩溃，租约到期后其他实例可以重新领取；旧实例恢复时，必须用版本或领取令牌做条件更新，防止它覆盖新实例的处理结果。
6. 超过重试上限的记录进入差错池或人工处理状态，不能把“重试次数用完”当作资金动作一定失败。

任务至少需要这些工程约束：

• 用 (status, next_retry_at) 或适配实际查询的等价索引筛选窗口，避免高频全表扫描。
• 每次领取有限批次，多实例通过租约、行锁或条件更新减少重复领取；租约只能协调任务执行，不能代替下游幂等。
• 记录最后错误、下次执行时间和处理版本，使用指数退避并设置上限。
• 补偿调用复用正式接口的幂等和状态检查，不能因为“这是补跑”就绕过校验。
• 监控中间态超时、堆积量、死信数量和人工处理时长。

PROCESSING 不能无限期占住记录。租约时长应覆盖正常处理窗口并允许续租；任务重启后扫描到期租约，再以条件更新接管。远程调用期间租约也可能过期，所以两个任务可能短暂并发调用同一操作，安全性最终仍依赖下游业务幂等键。

7.3 CDC：从数据库日志到业务事件#

CDC（Change Data Capture，变更数据捕获）解决的是“数据库里的已提交变更，怎样尽快送到下游”这个问题。应用照常提交本地事务，数据库同时把变更写入自己的事务日志，例如 MySQL 的 Binlog、PostgreSQL 的 WAL。

CDC 采集器读取这些日志，解析出表、主键和 INSERT、UPDATE、DELETE 等行变更，再把变更发送到消息系统。采集器会保存自己读到的位置，通常称为位点或 offset，以便重启后从断点继续。Debezium、Canal 和 Flink CDC 都属于这类实现，具体的事务边界、位点和投递语义要以所用产品的配置为准。

Binlog 和 WAL 首先服务于数据库自身的复制与恢复，它们不是业务消息队列：日志格式描述的是数据库行如何变化，不会直接说明“用户完成了一次支付”；数据库也会按保留策略清理旧日志。CDC 把短期数据库日志转成下游可消费的消息，并维护读取进度，但不会因此让源日志永久保留，也不会自动补全业务语义。

按时间顺序，这条链路发生了五件事：

1. 支付服务在本地事务中把支付单从 PAYING 更新为 CHANNEL_SUCCESS，事务提交。
2. 数据库把这次已提交的行变化写入 Binlog 或 WAL。
3. CDC 采集器从自己的位点继续读取日志，把变化包装成消息并发送到主题。
4. 账务消费者收到消息，在自己的本地事务中检查业务键、版本和状态，再写入分录。
5. 采集器或消费者在故障后从可恢复位置继续，因此同一变化可能再次到达，消费者必须把重复处理收敛到原来的结果。

图里的关键边界是：只有数据库事务提交后，变更才应作为 CDC 对下游发布的输入；CDC 把数据库变更送出去，但不替下游完成业务事务。它不是一个跨库提交协议，也不会自动判断“这次行更新代表扣款成功”这样的业务含义。

1
{
2
  "event_id": "payment-20260927-0001-v3",
3
  "source": "payment_db",
4
  "table": "payment_order",
5
  "operation": "UPDATE",
6
  "key": { "payment_id": "pay_20260927_0001" },
7
  "before": { "status": "PAYING", "version": 2 },
8
  "after": {
9
    "status": "CHANNEL_SUCCESS",
10
    "amount_minor": 10000,
11
    "currency": "CNY",
12
    "version": 3
13
  }
14
}

8.1 幂等键必须代表业务操作#

支付请求号、支付流水号、退款单号和业务事件主键可以识别“同一笔操作”。随机消息 ID 只能识别某次传输，不能识别业务被重新包装后再次发送。

幂等由三层共同完成：数据库唯一约束拒绝重复写入，状态机拒绝重复推进，业务规则检查累计金额和可操作范围。缓存锁可以减少重复请求压力，但会过期、丢失或在网络分区时失效，不能替代数据库约束。

8.2 状态机要拒绝乱序和非法转移#

状态机需要明确哪些状态是中间态，哪些状态是终态。旧回调不能覆盖新状态，普通重试不能逆转成功、冲正或人工接管等终态；非法转移应进入差错池，而不是静默丢弃。

回调、主动查询、消息消费和人工处理应共用同一套状态收敛规则。这样才能保证不同入口不会各自解释一套状态语义。

8.3 重试要有边界#

重试使用指数退避、最大次数和死信或差错状态。对于外部副作用，重试前必须确认幂等键是否保持不变，或者先查询上一次请求的结果；更换业务键会把一次不确定操作变成两次独立操作。

本地事务中不要批量调用远程服务或支付渠道。更稳妥的边界是：本地事务写入事实和待处理意图，提交后异步调用外部服务，把成功、失败或未知结果落库，再由补偿链路继续推进。

8.4 审计让结果可以被解释#

资金链路至少需要保存业务流水号、请求摘要、状态版本、操作来源、操作者、规则版本和全局 TraceID。原始回调、渠道响应和人工处理理由应可关联、可查询、可重放。

回调入口还必须验证签名、时间窗口和商户/渠道绑定，并用回调事件 ID 或业务键防止重放；验签成功后先持久化原始报文和接收时间，再进入状态收敛，不能把“收到 HTTP 200”当成业务处理成功。冲正、补记账和人工强制推进等修复动作需要最小权限、审批或双人复核，并把原状态、目标状态和修复理由写入不可随意覆盖的审计记录。

权限、密钥轮换、双人复核和紧急开关的完整设计属于另一条安全防线，详见权限审计与安全防线。

9.1 三层对账#

对账至少要同时看业务系统、外部系统和账务时间三个维度：

• 系统内对账：订单、支付流水、账务分录和余额是否相互一致，检查漏记、重复记账和余额漂移。
• 系统间对账：本地流水与支付渠道、银行、清算机构或商户账单是否一致。
• 时间维度对账：实时或准实时检查处理中异常，T+1 对账覆盖完整账务日，结算对账验证最终资金流向。

9.2 差异进入工作流#

对账发现差异后，不应直接修改余额或覆盖历史状态。差异应进入可追踪的差错池，再按类型执行主动查询、补单、重试、冲正、补差、退款或人工复核。

冲正不是删除错误流水，而是增加一笔有来源、有方向、有审批记录的反向分录。原始交易、差异证据、修复动作和最终结果必须保留，修复动作自身也要有幂等键。

外部渠道一致性的状态、回调、主动查询和账单模型见外部渠道一致性与对账。

9.3 为什么 CDC 和定时任务都不能替代对账#

渠道可能已经扣款，但回调没有到达，本地状态没有变化，CDC 和业务表扫描都可能找不到这笔外部事实。只有主动查询或渠道账单，才能发现本地没有记录的成功。

因此，对账不是“定时任务再跑一遍”，而是用另一组事实来源验证系统是否真的做对。没有对账的最终一致，只是对链路正常工作的假设。

例如，渠道账单显示 pay_20260927_0001 已扣款 100 元，但本地支付单仍为 UNKNOWN，账务分录也不存在。对账任务不能直接把余额加 100 元；它应先把差异写入差错池，核对渠道金额、币种和业务键，再选择补记账或冲正，并记录原始账单行和修复动作：

11.1 推荐的正常路径#

1. 支付服务在本地事务中创建支付单，写入 PENDING。
2. 同一事务写入 Outbox 事件，记录支付流水号和业务版本。
3. 渠道适配服务携带稳定幂等键发起支付。
4. 渠道返回成功、明确失败或未知结果，支付服务记录渠道事实；渠道成功不直接等于支付最终成功。
5. 账务服务在自己的本地事务中完成分录和余额更新，支付状态机在渠道事实与账务结果都满足条件后推进最终状态。
6. 订单服务更新订单；积分和商户通知通过消息异步消费。
7. 定时任务处理长时间停留在中间态的记录。
8. 内部和外部对账验证支付、订单、账务与渠道结果。

11.2 故障矩阵#

这条链路的核心取舍是：核心账务内部守住本地强一致，订单、积分和通知采用最终一致；所有异步入口共享幂等和状态机；最终结果由对账独立验证。

13.1 先画事实边界，不先选中间件#

把一次支付拆成可以独立证明的事实：

这张表会直接暴露错误的事务边界：如果系统只有一个“支付成功”字段，却无法区分渠道成功和账务成功，后续重试、查询和人工处理就没有可靠依据。

13.2 再给每个事实写不变量#

对这笔支付，至少要写出以下可以被数据库或任务验证的约束：

• pay_20260927_0001 只能对应一笔 100 元、一个币种和一个商户订单。
• 渠道成功凭证的业务键、金额和币种必须与支付单匹配。
• 同一支付流水最多生成一个有效账务记账批次（可能包含成组的借贷分录），重复消费只能读取已有结果。
• SUCCESS 只能在渠道事实和账务事实都存在后进入，迟到失败回调不能覆盖它。
• 渠道成功但账务失败时进入 SUSPENSE 或差错池，不能静默回到 PENDING 再发起一次扣款。

如果某条规则无法写成唯一键、条件更新、状态转换条件或对账规则，它还只是口头要求，不能作为一致性设计的依据。

13.3 按动作性质选择协调方式#

对每个跨边界动作问三个问题：资源是否需要先占住？动作是否能被业务补偿？结果是否必须低延迟传播？

这里的“优先考虑”不是自动选型。还要检查参与者是否支持幂等、查询和补偿；外部渠道只有一次扣款接口时，不能因为内部使用 TCC 就获得取消能力。

13.4 为每个远程动作列出三种结果#

不要只写“成功/失败”。对支付请求至少分别定义：

1. 明确成功：渠道返回可验证的成功凭证，金额、币种和业务键匹配。
2. 明确失败：返回码说明请求没有产生扣款效果，且业务规则允许重试或终止。
3. 结果未知：超时、连接断开或响应解析失败，无法判断渠道是否已经执行。

然后为 UNKNOWN 指定唯一收敛路径：先用同一业务键查询，查询不到时等待渠道账单或人工复核。禁止把未知结果直接改成失败，再用新业务键重新扣款。

13.5 用故障注入验证设计，而不是只读流程图#

对 pay_20260927_0001 至少模拟以下故障，并写出数据库最终应该留下什么：

如果设计无法为某个故障指出“哪条记录证明发生过什么”和“哪个动作可以安全重试”，就不能宣称它具备最终一致性。

13.6 再决定是否引入更重的组件#

完成前五步后再比较组件成本。检查定时扫描是否满足发现延迟，Outbox 表是否能承受事件量，CDC 的日志保留是否覆盖恢复窗口，消息系统是否提供可操作的死信和回放，TCC 协调器是否能持久化全局决定。

组件只改变触发、投递和协调方式，不改变幂等键、状态机、未知结果和对账这些业务约束。设计文档最终应能回答五个问题：事实写在哪里，重复如何处理，未知如何查询，差异如何修复，谁负责在终态前继续推进。