支付系统的分布式事务灾难：两阶段提交从理论到实践的血泪史

我们的支付系统差点酿成大祸。一笔订单在扣款成功后，商户却没收到钱，用户的订单状态还显示"待支付"。更恐怖的是，这种情况在压测中出现了上百次。距离双十一只有两周，老板直接发话：“解决不了就别上线！”

这个问题的根源，就是分布式事务处理不当。我们花了整整10天，从两阶段提交（2PC）的基础实现，到各种优化方案，再到最终的混合方案，总算是惊险过关。今天就来复盘这次"生死时速"，聊聊分布式事务的那些坑。

问题的根源：一笔支付涉及多少个系统？

先看看我们的支付流程涉及多少服务：

用户支付 → 支付网关 → 账务系统 → 银行接口 → 商户结算 → 订单系统 → 库存系统

每个环节都可能失败，最要命的是它们部署在不同的服务器上，有各自的数据库：

任何一个环节出错，都可能导致数据不一致。本地事务？不存在的。

两阶段提交：教科书方案的实践

2PC的基本实现

既然是分布式事务，第一个想到的就是两阶段提交。原理很简单：

第一阶段（准备阶段）：

1. 协调者问所有参与者：“你们都准备好了吗？”
2. 参与者执行事务但不提交，回答"Yes"或"No"

第二阶段（提交阶段）：

1. 如果都是"Yes"，协调者说：“提交！”
2. 如果有"No"，协调者说：“回滚！”

我们的初版实现：

public class PaymentCoordinator {
    private List<TransactionParticipant> participants;
    
    public boolean executeDistributedTransaction(PaymentOrder order) {
        // 第一阶段：准备
        Map<String, Boolean> prepareResults = new HashMap<>();
        
        for (TransactionParticipant participant : participants) {
            try {
                boolean prepared = participant.prepare(order);
                prepareResults.put(participant.getName(), prepared);
                
                if (!prepared) {
                    // 有人说No，直接进入回滚
                    rollbackAll(prepareResults.keySet());
                    return false;
                }
            } catch (Exception e) {
                // 准备阶段就失败了
                rollbackAll(prepareResults.keySet());
                return false;
            }
        }
        
        // 第二阶段：提交
        try {
            commitAll();
            return true;
        } catch (Exception e) {
            // 提交阶段失败，这是最糟糕的情况
            handleCommitFailure();
            return false;
        }
    }
}

第一次压测：惨不忍睹

信心满满地开始压测，结果：

数据不一致率达到3.2%！这意味着1000笔交易中有32笔会出现资金问题，这在金融系统中是绝对不能接受的。

2PC的问题分析

深入分析后，发现2PC的问题比想象的多：

最可怕的是"提交阶段失败"的情况。比如5个参与者，前3个提交成功，第4个网络超时，第5个还在等待。这时候数据已经不一致了，而且很难恢复。

两阶段提交的各种优化尝试

优化1：超时机制

第一个想法是加入超时机制：

// 给每个阶段设置超时时间
private static final long PREPARE_TIMEOUT = 3000; // 3秒
private static final long COMMIT_TIMEOUT = 2000;  // 2秒

public boolean prepareWithTimeout(PaymentOrder order) {
    Future<Boolean> future = executorService.submit(() -> {
        return participant.prepare(order);
    });
    
    try {
        return future.get(PREPARE_TIMEOUT, TimeUnit.MILLISECONDS);
    } catch (TimeoutException e) {
        // 超时当作失败处理
        future.cancel(true);
        return false;
    }
}

效果：

响应时间改善了，但数据一致性问题依然存在。

优化2：事务日志

为了解决协调者单点故障，我们引入了事务日志：

public class TransactionLog {
    // 事务状态
    enum Status {
        INIT,           // 初始化
        PREPARING,      // 准备中
        PREPARED,       // 已准备
        COMMITTING,     // 提交中
        COMMITTED,      // 已提交
        ABORTING,       // 回滚中
        ABORTED         // 已回滚
    }
    
    // 记录每个参与者的状态
    private Map<String, ParticipantStatus> participantStates;
    
    // 持久化到数据库
    public void persist() {
        // 写入MySQL，保证ACID
    }
}

事务恢复流程：

优化3：参与者优化

发现有些参与者天生就慢，需要区别对待：

现实的妥协：2PC的变种方案

补偿事务（Saga模式）

纯粹的2PC太重了，我们尝试了Saga模式：

public class PaymentSaga {
    // 定义每个步骤及其补偿操作
    private List<SagaStep> steps = Arrays.asList(
        new SagaStep("扣款", this::debitAccount, this::creditAccount),
        new SagaStep("创建订单", this::createOrder, this::cancelOrder),
        new SagaStep("扣库存", this::decreaseStock, this::increaseStock),
        new SagaStep("通知商户", this::notifyMerchant, this::cancelNotify)
    );
    
    public boolean execute(PaymentContext context) {
        int executedSteps = 0;
        
        try {
            for (SagaStep step : steps) {
                step.execute(context);
                executedSteps++;
            }
            return true;
        } catch (Exception e) {
            // 反向补偿
            compensate(context, executedSteps);
            return false;
        }
    }
}

Saga vs 2PC对比：

TCC模式（Try-Confirm-Cancel）

对于资金相关的核心操作，我们采用TCC：

public interface TccService {
    // Try：预留资源
    String tryPay(BigDecimal amount, String accountId);
    
    // Confirm：确认执行
    boolean confirmPay(String reservationId);
    
    // Cancel：取消预留
    boolean cancelPay(String reservationId);
}

实际效果对比：

最终方案：混合架构

经过反复权衡，我们最终采用了混合方案：

核心支付流程（强一致性要求）

使用优化后的2PC，但只包含最核心的操作：

订单状态更新（最终一致性）

使用消息队列+本地事务表：

-- 本地消息表
CREATE TABLE payment_event (
    id BIGINT PRIMARY KEY,
    order_id VARCHAR(64),
    event_type VARCHAR(32),
    payload TEXT,
    status TINYINT, -- 0:待发送 1:已发送 2:已确认
    retry_count INT DEFAULT 0,
    create_time TIMESTAMP,
    update_time TIMESTAMP,
    INDEX idx_status_create(status, create_time)
);

消息可靠性保证：

监控和补偿机制

建立了完善的监控体系：

双十一实战数据

最终方案在双十一的表现：

633笔不一致事务全部通过补偿机制自动修复，无一例资损！

踩坑总结

1. 2PC不是万能的

• 适合场景：参与者少、网络稳定、强一致性要求
• 不适合：长事务、跨机房、高并发

2. 设计要务实

不要追求完美的ACID，要根据业务特点选择：

• 资金：强一致性，可以牺牲性能
• 订单：最终一致性，追求高性能
• 通知：尽力而为，可以有损

3. 监控比方案更重要

再完美的方案也会出问题，关键是：

• 快速发现问题
• 快速定位原因
• 快速修复数据

4. 简单可靠 > 复杂完美

我们曾经设计过一个"完美"的分布式事务框架，支持各种模式，结果：

• 代码复杂，bug多
• 运维困难，不敢改
• 性能差，扛不住压力

最后还是回归简单方案，反而稳定可靠。

写在最后

分布式事务是分布式系统永恒的难题。这次支付系统的改造让我深刻体会到：没有银弹，只有权衡。

两阶段提交在理论上很美好，但实践中问题重重。最终我们通过分层设计、混合方案、完善监控，才勉强达到生产要求。这个过程充满了妥协和取舍。

如果你也在做分布式事务，我的建议是：

1. 先想清楚一致性要求，不要过度设计
2. 从简单方案开始，逐步优化
3. 监控和补偿比预防更重要
4. 保持敬畏之心，分布式系统总会出问题的

记住：分布式事务的本质是在CAP中找平衡，完美是不存在的，适合才是最好的。

最后，如果你有更好的分布式事务实践经验，欢迎交流！在这个领域，我们都是学生。