MySQL分布式事务解决方案：XA协议与柔性事务实践

1. MySQL分布式事务的核心挑战与解决思路

在微服务架构成为主流的今天，一个完整的业务操作往往需要跨多个数据库实例甚至不同服务。我经历过一个电商订单系统的重构项目：创建订单需要同时操作订单库、库存库和用户积分库，这三个数据库分别部署在不同服务器上。当库存扣减成功但积分扣除失败时，就会产生数据不一致的问题。

分布式事务要解决的核心问题就是保证这种跨资源操作的ACID特性，特别是原子性（Atomicity）和一致性（Consistency）。MySQL作为最广泛使用的关系型数据库，提供了几种典型的解决方案：

• XA协议：MySQL官方支持的分布式事务标准，采用两阶段提交（2PC）机制
• 柔性事务：如TCC、SAGA模式，通过业务补偿实现最终一致性
• 消息队列：利用本地消息表+异步消息实现事务解耦

关键考量点：强一致性要求越高，系统可用性和性能往往越低。根据CAP理论，网络分区（P）发生时，必须在一致性（C）和可用性（A）之间做出选择。

2. XA协议实现原理与实战细节

2.1 XA协议的工作机制

XA协议的核心是两阶段提交（2PC），我通过一个转账场景来说明其工作原理：

1. 准备阶段（Prepare）：

   • 协调者向所有参与者发送prepare请求
   • 每个参与者执行事务但不提交，记录undo/redo日志
   • 参与者锁定相关资源，防止其他事务修改
   • 参与者向协调者反馈准备结果（成功/失败）

2. 提交阶段（Commit/Rollback）：

   • 如果所有参与者都prepare成功，协调者发送commit指令
   • 任一参与者prepare失败，协调者发送rollback指令
   • 参与者完成最终提交或回滚，释放锁资源

sql复制-- MySQL中XA事务的典型SQL序列
XA START 'transaction_id';  -- 开启XA事务
UPDATE account SET balance = balance - 100 WHERE user_id = 1;
XA END 'transaction_id';
XA PREPARE 'transaction_id'; -- 第一阶段准备
XA COMMIT 'transaction_id';  -- 第二阶段提交

2.2 XA协议的局限性及应对方案

在实际项目中，我们发现XA协议存在几个典型问题：

1. 同步阻塞问题：

   • 参与者prepare后会一直持有锁，直到收到协调者指令
   • 网络延迟或协调者故障会导致资源长时间锁定
   • 解决方案：设置合理的超时时间，超时后自动回滚

2. 单点故障风险：

   • 协调者宕机会使事务处于不确定状态
   • 解决方案：引入协调者集群，采用ZooKeeper选举新协调者

3. 数据不一致场景：

   • 部分参与者收到commit而其他参与者未收到
   • 解决方案：记录事务日志，定时任务扫描恢复

实战经验：XA事务不适合高并发场景。我们在支付系统中测试发现，当TPS超过500时，XA事务的失败率会显著上升。对于核心支付链路，我们最终采用了XA+异步补偿的混合方案。

3. 柔性事务的典型实现模式

3.1 TCC模式详解

TCC（Try-Confirm-Cancel）是我们目前在订单系统中使用的主要方案。以创建订单为例：

1. Try阶段：

   • 库存服务：预扣库存（状态为"冻结"）
   • 积分服务：预扣积分（状态为"待使用"）
   • 订单服务：生成预订单（状态为"待确认"）

2. Confirm阶段：

   • 所有Try成功则执行Confirm
   • 库存服务：将冻结库存标记为已扣减
   • 积分服务：将预扣积分标记为已使用
   • 订单服务：将预订单标记为已创建

3. Cancel阶段：

   • 任一Try失败则执行Cancel
   • 库存服务：释放冻结的库存
   • 积分服务：返还预扣的积分
   • 订单服务：取消预订单

java复制// TCC模式的典型代码结构
public class OrderService {
    @Transactional
    public void createOrder(OrderDTO orderDTO) {
        // Try阶段
        inventoryService.freezeStock(orderDTO.getItems());
        pointsService.freezePoints(orderDTO.getUserId(), orderDTO.getPoints());
        orderMapper.createTemporaryOrder(orderDTO);
        
        // 记录TCC上下文
        TccContext context = new TccContext();
        context.setXid(TransactionContext.getXID());
        tccLogService.save(context);
    }
    
    @Transactional
    public void confirmOrder(String xid) {
        TccContext context = tccLogService.get(xid);
        inventoryService.confirmStock(context.getItems());
        pointsService.confirmPoints(context.getUserId());
        orderMapper.confirmOrder(context.getOrderId());
    }
    
    @Transactional 
    public void cancelOrder(String xid) {
        TccContext context = tccLogService.get(xid);
        inventoryService.cancelStock(context.getItems());
        pointsService.cancelPoints(context.getUserId());
        orderMapper.cancelOrder(context.getOrderId());
    }
}

3.2 SAGA模式实践

对于长流程业务（如机票+酒店套餐预订），我们采用SAGA模式：

1. 将整个业务流程拆分为多个本地事务
2. 每个事务提供对应的补偿操作
3. 正向执行成功则继续下一个事务
4. 任一事务失败则逆向执行已成功的补偿操作

mermaid复制graph LR
    A[开始] --> B[机票预订]
    B --> C{成功?}
    C -->|是| D[酒店预订]
    C -->|否| E[取消机票]
    D --> F{成功?}
    F -->|是| G[完成]
    F -->|否| H[取消酒店]
    H --> E

避坑指南：SAGA模式必须保证每个补偿操作是幂等的。我们曾遇到因网络重试导致的多次补偿，后来通过为每个操作添加唯一执行令牌（token）解决了这个问题。

4. 消息队列方案的设计与实现

4.1 本地消息表模式

这是我们最常用的最终一致性方案，核心流程：

1. 业务操作与消息记录在同一个本地事务中
2. 定时任务扫描未发送的消息进行重试
3. 消费者保证幂等处理

sql复制-- 本地消息表设计示例
CREATE TABLE transaction_message (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    biz_id VARCHAR(64) NOT NULL COMMENT '业务ID',
    topic VARCHAR(128) NOT NULL COMMENT '消息主题',
    content TEXT NOT NULL COMMENT '消息内容',
    status TINYINT NOT NULL COMMENT '0-待发送 1-已发送 2-已消费',
    retry_count INT DEFAULT 0 COMMENT '重试次数',
    create_time DATETIME NOT NULL,
    update_time DATETIME NOT NULL,
    UNIQUE KEY uk_biz_topic (biz_id, topic)
) ENGINE=InnoDB;

4.2 RocketMQ事务消息

对于高吞吐场景，我们采用RocketMQ的事务消息：

1. 发送半消息（对消费者不可见）
2. 执行本地事务
3. 根据本地事务结果提交或回滚消息

java复制// RocketMQ事务消息示例
public class OrderService {
    private TransactionMQProducer producer;
    
    @Transactional
    public void createOrder(OrderDTO orderDTO) {
        // 1. 创建订单
        orderMapper.insert(orderDTO);
        
        // 2. 发送事务消息
        Message msg = new Message("order_topic", JSON.toJSONBytes(orderDTO));
        TransactionSendResult result = producer.sendMessageInTransaction(msg, orderDTO);
        
        // 3. 处理发送结果
        if (!result.getLocalTransactionState().equals(LocalTransactionState.COMMIT_MESSAGE)) {
            throw new RuntimeException("消息发送失败");
        }
    }
}

// 事务监听器
public class OrderTransactionListener implements TransactionListener {
    @Override
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        try {
            OrderDTO orderDTO = (OrderDTO) arg;
            // 执行本地事务（如扣减库存）
            inventoryService.deductStock(orderDTO.getItems());
            return LocalTransactionState.COMMIT_MESSAGE;
        } catch (Exception e) {
            return LocalTransactionState.ROLLBACK_MESSAGE;
        }
    }
    
    @Override
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        // 检查本地事务状态
        String orderId = msg.getKeys();
        Order order = orderMapper.selectById(orderId);
        return order != null ? LocalTransactionState.COMMIT_MESSAGE 
                           : LocalTransactionState.ROLLBACK_MESSAGE;
    }
}

4.3 消息方案常见问题处理

1. 消息重复消费：

   • 为每个业务操作生成唯一ID
   • 消费前检查去重表
   • 实现幂等处理逻辑

2. 消息积压处理：

   • 监控消息堆积量
   • 动态增加消费者实例
   • 降级非核心业务的消息处理

3. 事务状态不一致：

   • 定期核对消息与业务数据状态
   • 建立异常处理工单系统
   • 人工介入兜底机制

5. 混合方案设计与选型建议

5.1 典型业务场景分析

根据我们的实践经验，不同业务场景适合不同方案：

5.2 混合架构设计示例

我们的交易系统采用了分层事务策略：

1. 支付核心层：

   • 采用XA协议保证资金操作强一致
   • 事务超时时间设置为3秒
   • 每日对账补正机制

2. 订单履约层：

   • 使用TCC模式管理库存和优惠券
   • 每个Try操作设置30秒超时
   • 每小时执行过期订单检查

3. 积分和通知层：

   • 通过RocketMQ事务消息异步处理
   • 允许最多3天的最终一致
   • 提供手动补发功能

5.3 性能优化关键点

1. XA协议优化：

   • 减少参与节点数量
   • 使用MySQL 5.7+的XA优化
   • 设置合理的innodb_lock_wait_timeout

2. TCC模式优化：

   • 合并多个Try操作为一个复合操作
   • 采用异步Confirm/Cancel
   • 实现批量资源预留

3. 消息方案优化：

   • 压缩消息体积
   • 批量发送消息
   • 消费者并行处理

个人经验：没有任何一种方案能解决所有问题。我们现在的策略是：能用本地事务就不用分布式事务；必须用分布式事务时，优先考虑最终一致性方案；只有对资金、库存等核心数据才使用强一致性方案。