3. 分布式事务（上）：XA协议、2PC（两阶段提交）的原理、在风控扣款场景中的实践与痛点

好，咱们今天聊点硬核的——分布式事务。说实话，我在风控系统里摸爬滚打这么多年，最头疼的就是这个。你想想看，一个用户下单，我们要扣他的信用额度、冻结他的优惠券、记录他的行为日志，这三个操作分布在三个不同的服务里。任何一个失败了，数据就乱了。怎么办？

嗯，经典的方案就是两阶段提交（2PC），以及它背后的XA协议。今天我就把这块掰开了讲清楚。

3.1 什么是XA协议？

XA协议是X/Open组织定义的一个分布式事务处理规范。说白了，它定义了一个“全局事务管理器”和多个“资源管理器”之间的交互接口。资源管理器就是你的数据库、消息队列这些。全局事务管理器负责协调它们。

我个人习惯把XA协议理解成一个“分布式事务的交通规则”。它规定了：

• 事务管理器怎么通知各个资源管理器“准备提交”
• 资源管理器怎么回复“我准备好了”或“我失败了”
• 事务管理器怎么下达“提交”或“回滚”的指令

这里有个关键点：XA协议要求资源管理器（比如MySQL、Oracle）本身支持XA。不是所有数据库都支持，或者支持的程度不一样。我在项目中遇到过，用了一个不太知名的数据库，结果XA支持有bug，折腾了好几天。

3.2 两阶段提交（2PC）的原理

2PC是XA协议最经典的实现方式。名字就叫“两阶段”，所以它分两步走。

第一阶段：准备阶段（Vote Phase）

事务管理器问所有参与者：“我要提交了，你们准备好了吗？”

每个参与者做两件事：

1. 执行事务操作，但不提交（写入undo/redo日志）
2. 回复“Yes”或“No”

注意，这个阶段参与者已经锁住了资源。比如扣款操作，钱已经冻结了，但还没真正扣走。

第二阶段：提交阶段（Commit Phase）

事务管理器根据第一阶段的投票结果做决策：

• 如果所有人都回复“Yes”，就广播“Commit”
• 如果有人回复“No”或超时，就广播“Rollback”

参与者收到指令后，执行真正的提交或回滚。

我画了一张图，帮你理解这个流程：

3.3 在风控扣款场景中的实践

好了，理论说完了，咱们看看实际怎么用。假设一个典型的扣款场景：

• 账户服务：扣减用户余额
• 风控服务：记录扣款流水，更新风控指标
• 营销服务：核销一张优惠券

这三个操作必须同时成功或同时失败。用2PC来实现，伪代码如下：

// 伪代码：风控扣款2PC实现
public class RiskControlTransaction {

    @Resource
    private AccountService accountService;  // 账户服务
    @Resource
    private RiskService riskService;        // 风控服务
    @Resource
    private CouponService couponService;    // 营销服务

    public boolean deductWith2PC(User user, BigDecimal amount, String couponId) {
        // 第一阶段：准备
        boolean accountPrepared = accountService.prepareDeduct(user, amount);
        boolean riskPrepared = riskService.prepareRecord(user, amount);
        boolean couponPrepared = couponService.prepareUse(user, couponId);

        // 检查是否全部准备成功
        if (accountPrepared && riskPrepared && couponPrepared) {
            // 第二阶段：提交
            accountService.commitDeduct(user);
            riskService.commitRecord(user);
            couponService.commitUse(user);
            return true;
        } else {
            // 回滚
            if (accountPrepared) accountService.rollbackDeduct(user);
            if (riskPrepared) riskService.rollbackRecord(user);
            if (couponPrepared) couponService.rollbackUse(user);
            return false;
        }
    }
}

3.4 2PC的痛点分析

说实话，2PC看起来很完美，对吧？但实际用起来，坑不少。我总结了几个最要命的：

痛点	具体表现	影响
同步阻塞	第一阶段锁定资源后，所有参与者必须等待TM的最终决策。期间资源被锁住，其他事务无法操作。	高并发场景下，数据库连接池很快耗尽，系统吞吐量急剧下降。
单点故障	事务管理器TM是单点。如果TM在第二阶段挂了，所有参与者都卡在“已准备”状态，无法释放资源。	数据不一致，需要人工介入清理。我见过一个案例，TM宕机导致几万笔订单卡住，运维同学加班到凌晨。
数据不一致风险	第二阶段提交时，如果TM给部分参与者发了Commit，但自己挂了，没发出去的参与者就永远收不到指令。	部分提交、部分未提交，数据就乱了。
性能开销大	每个事务至少需要两轮网络通信，加上磁盘日志写入，延迟明显增加。	风控扣款场景下，用户可能等很久才能看到结果。用户体验差。

3.5 我的实践经验与建议

做了这么多年风控系统，我对2PC的态度是：能用，但别滥用。给你几个建议：

• 控制事务粒度：不要把太多服务塞进一个2PC事务里。3-5个参与者是上限，再多就失控了。
• 设置超时机制：每个阶段都要有超时时间。我一般设3秒，超过就自动回滚。
• 做好日志记录：每个参与者的准备、提交、回滚操作都要记日志。出问题时，日志就是救命稻草。
• 考虑替代方案：如果并发高，可以考虑TCC（Try-Confirm-Cancel）或者Saga模式。下节课我会详细讲。

嗯，2PC这块就聊到这儿。它是个经典方案，但绝不是银弹。理解它的原理和痛点，你才能在合适的场景用对工具。下次遇到分布式事务问题，至少知道从哪里下手了。

公众号:蓝海资料掘金营，微信deep3321