4. 分布式事务模式

银行账务系统对一致性的要求远高于一般互联网业务：一笔跨行转账、一次积分扣减、一次理财申购，往往同时涉及核心账务、支付网关、积分系统、理财登记系统等多个独立数据源。分布式事务模式的选择，直接决定了账务最终一致性的实现路径、性能上限与故障恢复能力。本节围绕六种主流模式展开原理剖析，并结合银行账务场景给出适用性判断。

一、核心原理：从强一致到最终一致

分布式事务的本质，是在多个独立资源管理器之间协调提交或回滚。2PC（两阶段提交）通过准备与提交两个阶段，由协调者统一决策，追求强一致性；3PC 在 2PC 基础上引入预提交与超时机制，降低协调者单点阻塞风险。TCC（Try-Confirm-Cancel）将业务逻辑显式拆分为资源预留、确认、取消三个阶段，把一致性控制权交给业务代码。SAGA 将长事务拆为一系列本地事务，通过正向执行与反向补偿实现最终一致。本地消息表与事务消息则借助消息中间件，把跨系统调用转化为异步可靠投递。

二、方法流程与关键机制

以 TCC 为例，其流程可抽象为：Try 阶段冻结或预占资金，Confirm 阶段完成实际扣减，Cancel 阶段释放预占。SAGA 则依赖补偿接口，每一步正向操作都需对应一个可逆操作。本地消息表把消息与业务数据写入同一本地事务，再由独立投递器扫描发送；事务消息由消息中间件保证“半消息”与本地事务的原子性。

// TCC 三段式伪代码示意
try {
    account.freeze(orderId, amount);   // 预占资金
} catch (Exception e) {
    throw new TccException("Try失败");
}
// 全局事务协调器决定
confirm(orderId);   // 实际扣减
// 或
cancel(orderId);    // 释放预占

下表对六种模式在银行账务场景下的关键维度进行对比：

三、银行账务场景案例

场景一：跨行转账。核心账务扣款与支付网关出款分属不同系统，若采用 2PC，协调者故障会导致资源长期锁定，影响联机交易。实践中更常见的是“本地消息表 + 对账补偿”：核心扣款成功后写入本地消息表，投递器异步通知支付网关，日终对账发现不一致再触发补偿。

场景二：积分与账务联动。用户消费后需扣减积分并增加账务流水。TCC 可先冻结积分，待账务确认后再 Confirm；若账务失败则 Cancel 释放积分。该模式在积分预占、优惠券核销中较为成熟。

场景三：理财申购。申购涉及资金冻结、份额登记、确认份额多个长步骤，SAGA 将每步本地事务化，失败时按反向顺序补偿，适合流程长、参与方多的业务。

四、误区与复盘

误区一：认为 TCC 一定优于 2PC。TCC 的业务侵入性极高，若 Try 阶段资源预占设计不当，会出现“悬挂”或“空回滚”，反而增加账务差错。误区二：把 SAGA 当作万能补偿。补偿操作本身也可能失败，必须配合重试、人工干预与对账兜底。误区三：忽视幂等。消息重复投递在银行场景中几乎必然发生，所有账务接口都必须支持幂等键。

复盘来看，模式选型应遵循“账务等级决定一致性强度，业务形态决定协调方式”的原则。核心账务优先本地事务；支付、积分等可预占场景用 TCC；长流程编排用 SAGA；异步解耦用本地消息表或事务消息。最终一致性不是技术炫技，而是银行账务在可用性、性能与准确性之间的工程平衡。