-- 业务表
CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id BIGINT,
    amount DECIMAL(10,2),
    status VARCHAR(20)
);

-- 消息表
CREATE TABLE message_outbox (
    id BIGINT PRIMARY KEY,
    message_type VARCHAR(50),
    payload TEXT,
    status VARCHAR(20),
    created_time TIMESTAMP,
    processed_time TIMESTAMP
);

操作流程

开启事务：开启数据库事务
业务操作：插入订单记录
存储消息：在消息表中插入待发送消息
提交事务：提交数据库事务
消息发送：通过单独的进程或定时任务发送消息

优势与劣势

优势

原子性保证：消息和业务数据在同一事务中，保证原子性
简单可靠：实现相对简单，可靠性高
易于维护：所有数据都在同一数据库中，便于维护

劣势

耦合性：业务表和消息表耦合在一起
扩展性：随着消息量增加，可能影响业务表性能
技术栈限制：需要使用支持事务的数据库

指数退避：重试间隔按指数增长，避免系统过载
最大重试次数：设置最大重试次数，避免无限重试
死信队列：超过最大重试次数的消息进入死信队列，人工处理

重试实现

@Component
public class MessageRetryHandler {
    
    @Retryable(value = {Exception.class}, 
               maxAttempts = 5, 
               backoff = @Backoff(delay = 1000, multiplier = 2))
    public void sendMessage(Message message) {
        // 发送消息的逻辑
        messageProducer.send(message);
    }
    
    @Recover
    public void recover(Exception e, Message message) {
        // 重试失败后的处理逻辑
        deadLetterQueue.send(message);
    }
}

幂等性设计

幂等性是指同一个操作多次执行产生的结果是一致的，这是分布式系统中非常重要的设计原则。

幂等性实现方法

唯一标识符：为每个操作分配唯一标识符
状态检查：在执行操作前检查状态
数据库约束：利用数据库的唯一约束防止重复操作

幂等性实现示例

@Service
public class OrderService {
    
    @Transactional
    public void processOrder(OrderRequest request) {
        // 检查订单是否已处理
        if (orderRepository.existsByRequestId(request.getRequestId())) {
            return; // 已处理，直接返回
        }
        
        // 创建订单
        Order order = new Order();
        order.setRequestId(request.getRequestId());
        order.setUserId(request.getUserId());
        order.setAmount(request.getAmount());
        order.setStatus(OrderStatus.CREATED);
        
        orderRepository.save(order);
        
        // 其他业务逻辑
    }
}

实际应用场景

电商订单处理

在电商系统中，用户下单后需要进行多个操作：

创建订单
扣减库存
发送支付通知
发送物流通知

使用本地事务 + 消息队列模式可以很好地处理这种场景：

@Service
public class OrderService {
    
    @Transactional
    public Order createOrder(OrderRequest request) {
        // 1. 创建订单
        Order order = new Order();
        order.setUserId(request.getUserId());
        order.setProductId(request.getProductId());
        order.setQuantity(request.getQuantity());
        order.setStatus(OrderStatus.PENDING);
        orderRepository.save(order);
        
        // 2. 存储消息
        Message message = new Message();
        message.setType("ORDER_CREATED");
        message.setPayload(objectMapper.writeValueAsString(order));
        message.setStatus(MessageStatus.PENDING);
        messageRepository.save(message);
        
        return order;
    }
}

支付系统

在支付系统中，用户支付成功后需要进行多个操作：

更新账户余额
记录交易日志
发送通知消息
更新订单状态

@Service
public class PaymentService {
    
    @Transactional
    public void processPayment(PaymentRequest request) {
        // 1. 更新账户余额
        accountService.debit(request.getAccountId(), request.getAmount());
        
        // 2. 记录交易日志
        transactionLogService.record(request);
        
        // 3. 存储消息
        PaymentMessage message = new PaymentMessage();
        message.setPaymentId(request.getPaymentId());
        message.setAccountId(request.getAccountId());
        message.setAmount(request.getAmount());
        message.setStatus(MessageStatus.PENDING);
        messageRepository.save(message);
    }
}

与其他模式的对比

与2PC对比

特性	本地事务 + 消息队列	2PC
一致性	最终一致性	强一致性
性能	高	低
可用性	高	低
实现复杂度	低	高
故障恢复	简单	复杂

与TCC对比

特性	本地事务 + 消息队列	TCC
业务侵入性	低	高
实现复杂度	低	高
一致性	最终一致性	强一致性
适用场景	通用场景	复杂业务场景

与Saga对比

特性	本地事务 + 消息队列	Saga
协调方式	消息队列	编排/协作
一致性	最终一致性	最终一致性
回滚机制	无自动回滚	补偿事务
实现复杂度	低	中等

最佳实践

设计原则

消息可靠性：确保消息不丢失
幂等性设计：防止重复消费
状态管理：合理管理消息和业务状态
监控告警：建立完善的监控体系

性能优化

批量处理：批量发送和处理消息
异步处理：将非关键操作异步化
缓存机制：合理使用缓存提升性能
分区策略：通过分区提升并发处理能力

故障处理

超时机制：设置合理的超时时间
重试机制：实现智能重试策略
死信队列：处理无法正常处理的消息
人工干预：建立人工处理流程

总结

本地事务 + 消息队列模式是一种实用且广泛应用的分布式事务解决方案。它通过将分布式事务拆分为多个本地事务，利用消息队列来协调这些本地事务的执行，最终达到数据一致性。

这种模式放弃了强一致性，采用最终一致性，但在实际应用中具有更好的性能和可用性。通过合理的设计和实现，可以满足大多数业务场景的需求。

在后续章节中，我们将继续探讨其他分布式事务模式，如TCC、Saga等，帮助你全面了解分布式事务的各种解决方案，并能够在实际项目中正确选择和应用这些模式。