3. 金融业务场景剖析
在金融系统中，分布式事务并不是一个抽象的技术名词，而是由业务链路倒逼出来的刚性需求。支付、清算、账务、理财、信贷五类场景，对一致性、时效性、可追溯性和资金安全的要求各不相同，但共同点是：一旦跨服务、跨库、跨机构，本地事务便无法兜底。理解这些场景的差异，是选择 Saga、TCC 还是 Outbox 的前提。
一、核心原理：金融分布式事务的四个约束维度
金融业务对分布式事务的诉求，可以归纳为四个维度：原子性（资金不能凭空产生或消失）、隔离性（并发扣款不能超卖）、时效性（支付要秒级响应，清算可准实时）、可追溯性（每一笔状态变更都要有凭证）。这四个维度在不同场景中的权重不同，直接决定了事务模型的选择。
关键判断：强一致且短事务优先考虑 TCC；长流程且可补偿优先考虑 Saga；只要求最终一致且需可靠投递优先考虑 Outbox。金融场景往往不是三选一，而是组合使用。
二、五类场景的需求与痛点对照
| 场景 | 典型链路 | 一致性要求 | 主要痛点 | 适配模式 |
|---|---|---|---|---|
| 支付 | 下单→支付→渠道扣款→回调 | 强一致、秒级 | 渠道超时、重复回调、状态悬挂 | TCC + Outbox |
| 清算 | 交易汇总→轧差→结算→对账 | 最终一致、准实时 | 批量失败、差错处理、幂等重跑 | Saga |
| 账务 | 记账→分录→余额更新→试算 | 强一致、可追溯 | 借贷不平、并发更新、热点账户 | TCC / 本地消息表 |
| 理财 | 申购→份额确认→收益分配→赎回 | 最终一致、T+1 | 确认延迟、份额精度、跨日切 | Saga + Outbox |
| 信贷 | 授信→放款→还款→核销 | 最终一致、长流程 | 放款与记账不同步、逾期状态漂移 | Saga |
从表中可以看出，支付和账务更偏向强一致短事务，清算、理财、信贷则更适合长流程补偿。真正的难点在于：同一笔业务往往横跨多个场景，例如一次支付会触发账务记账和后续清算，这就要求事务模型能够分层组合。
三、方法流程：从业务链路到事务边界的拆解
面对一个金融业务需求，建议按以下步骤拆解分布式事务边界：
- 识别资金流与信息流：区分哪些步骤涉及真实资金变动，哪些只是状态记录。
- 划定事务边界：将强一致步骤收敛到同一服务或同一数据库事务内。
- 标记可补偿点：对跨服务步骤定义正向操作与逆向补偿操作。
- 设计幂等键：以业务流水号作为全局幂等标识，贯穿全链路。
- 选择事务模式：短事务强一致用 TCC，长流程用 Saga，异步可靠投递用 Outbox。
- 补充对账与兜底：任何分布式事务都必须有对账和人工干预通道。
// 支付场景中的幂等与状态机示例
public enum PayState {
INIT, PAYING, SUCCESS, FAILED, UNKNOWN
}
// 渠道回调必须幂等处理
if (order.getState() == PayState.SUCCESS) {
return "already processed";
}
// 状态机只允许合法迁移
if (!order.getState().canTransferTo(PayState.SUCCESS)) {
throw new IllegalStateException("invalid state transfer");
}这段代码体现了金融场景的两个基本纪律：状态迁移必须合法，回调必须幂等。缺少任何一条，分布式事务都会在异常路径上失控。
四、案例与场景：支付回调引发的账务不一致
某支付系统在渠道回调时，先更新支付单为成功，再调用账务服务记账。由于网络抖动，账务服务超时，支付单已成功但账务未记账。此时用户看到支付成功，但账户余额未变，形成资金差错。
复盘发现三个问题：一是支付单与账务未在同一事务边界内；二是回调没有幂等保护，重试导致重复记账风险；三是缺少对账兜底。改进方案是：支付单更新与 Outbox 消息写入同一本地事务，由 Outbox 异步投递账务服务，账务服务消费时幂等处理，同时每日对账补偿差异。
常见误区：认为“加了消息队列就等于最终一致”。实际上，消息发送与本地事务若不在同一原子操作内，仍会出现消息丢失或重复。Outbox 模式的核心正是把消息写入与业务写入放在同一个本地事务中。
五、误区复盘与选型建议
- 误区一：所有场景都用 TCC。 TCC 需要每个服务实现 Try/Confirm/Cancel，开发成本高，长流程中补偿逻辑复杂，不适合清算、信贷等长链路。
- 误区二：Saga 不需要幂等。 Saga 的补偿和重试都会重复调用，幂等是底线而非可选项。
- 误区三：Outbox 可以替代对账。 Outbox 解决可靠投递，但无法发现业务逻辑错误，对账仍是金融系统的最后防线。
- 误区四：忽略状态悬挂。 支付超时后渠道又成功，若没有状态机约束，会出现“已关闭又成功”的悬挂状态。
选型口诀：短、强、快用 TCC；长、松、补用 Saga；异步、可靠、解耦用 Outbox。 金融系统通常是三者组合，而非单一模式。
回到本节的核心：金融分布式事务的选型，从来不是技术偏好问题，而是业务一致性要求、流程长度和可补偿性共同决定的结果。支付、清算、账务、理财、信贷五类场景各有侧重，但都离不开幂等、状态机、对账这三条底线。只有先把业务链路拆清楚，Saga、TCC 与 Outbox 才有落地的意义。