事务与消息中间件：分布式系统中的可见性边界问题

一、问题的本质：时空错位的一致性困境

在微服务架构中，我们常遇到这样的场景：一个业务方法既要修改数据库状态，又要发送消息到MQ触发下游服务。表面看，这只是简单的"写DB+发消息"，但细究其执行时序，隐藏着一个致命陷阱【本文以@Transactional为例】：

typescript 复制代码

@Transactional
public void createUser(User user) {
    userRepository.save(user); // 1. 数据库操作
    mqProducer.sendUserCreatedEvent(user.getId()); // 2. 发送MQ消息
    ......
}

问题核心 ：当事务尚未提交时，MQ消息已被发出。下游消费者立即处理该消息，尝试查询刚刚创建的用户数据，却因事务尚未提交而查询不到，导致业务失败。

这不是简单的代码bug，而是分布式系统中时空错位的典型表现------事务边界与消息传递在时间维度上不同步，造成数据可见性不一致。正如物理学中的相对论，不同参照系（服务）对"现在"的定义并不相同。

1.1 事务提交时机的迷思

Spring的@Transactional背后运作机制常被误解：

关键洞察：事务提交发生在方法执行结束之后 ，而非数据库操作之后。当mqProducer.send()执行时，事务尚未提交，数据对其他连接不可见。

二、如何识别这种场景？

在代码审查中，警惕同时出现的以下模式：

@Transactional注解的方法内直接调用MQ发送
事务方法内调用异步方法(@Async)
事务方法内触发远程服务调用
事务方法中操作缓存(如Redis)

三、解决方案

3.1 事务同步机制：让消息在提交后发送

利用Spring的TransactionSynchronizationManager注册回调：

typescript 复制代码

@Service
public class SafeUserService {
    
    @Transactional
    public void createUser(User user) {
        userRepository.save(user);
        
        // 注册事务提交后的回调
        TransactionSynchronizationManager.registerSynchronization(
            new TransactionSynchronization() {
                @Override
                public void afterCommit() {
                    mqProducer.sendUserCreatedEvent(user.getId());
                }
            }
        );
    }
}

3.2 事务消息表：本地事务与消息的原子性

将消息作为业务数据的一部分，写入同一事务：

typescript 复制代码

@Transactional
public void createUser(User user) {
    userRepository.save(user);
    // 同一事务中保存消息
    messageRepository.save(new OutboxMessage("user.created", user.getId()));
}

// 独立的定时任务/监听器
@Scheduled(fixedDelay = 1000)
@Transactional
public void sendPendingMessages() {
    List<OutboxMessage> messages = messageRepository.findPending(100);
    for (OutboxMessage message : messages) {
        if (mqProducer.send(message)) {
            message.setSent(true);
        }
    }
}

优势：本地事务保证数据与消息的一致性；

劣势：增加了系统复杂度，需要处理消息表清理、重复发送等问题。

3.3 事件溯源：重构数据与事件的关系

将事件本身作为首要数据存储，而非副产品：

csharp 复制代码

@Transactional
public void createUser(User user) {
    // 创建领域事件(持久化)
    UserCreatedEvent event = new UserCreatedEvent(user);
    eventRepository.save(event);
    
    // 业务数据从事件中派生
    userRepository.save(user);
}

// 事件处理器(独立事务)
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleUserCreated(UserCreatedEvent event) {
    mqProducer.send(event);
}

这种模式将事件提升为一等公民，从根本上解决了时序问题，但需要对领域模型进行重构。

四、架构层面的思考

4.1 最终一致性 vs 强一致性

认识到分布式系统中强一致性的高昂代价，大多数业务场景可接受最终一致性：

ini 复制代码

public void handleUserCreatedEvent(String userId) {
    User user = null;
    int retryCount = 0;
    // 重试机制，等待数据可见
    while (user == null && retryCount < 5) {
        user = userRepository.findById(userId).orElse(null);
        if (user == null) {
            Thread.sleep(100 * (long)Math.pow(2, retryCount)); // 指数退避
            retryCount++;
        }
    }
    
    if (user == null) {
        // 重试失败，进入死信队列或人工干预
        deadLetterService.handleUnresolvedEvent(userId);
        return;
    }
    
    // 正常处理
    processUser(user);
}

4.2 事务边界设计原则

单一职责原则：事务方法应只负责数据一致性，不混杂外部通信
最小事务原则：事务范围应当尽可能小，只包含必要的数据库操作
分层明确原则：将事务控制、业务逻辑、集成通信分层实现

java 复制代码

// 优化后的分层设计
@Service
@RequiredArgsConstructor
public class UserService {
    
    private final UserRepository userRepository;
    private final TransactionalEventPublisher eventPublisher;
    
    @Transactional
    public void createUser(CreateUserCommand command) {
        User user = new User(command.getName(), command.getEmail());
        userRepository.save(user);
        
        // 仅发布领域事件，不关心传输细节
        eventPublisher.publishAfterCommit(new UserCreatedEvent(user.getId()));
    }
}

@Component
@RequiredArgsConstructor
class UserEventConsumer {
    private final UserRepository userRepository;
    private final EmailService emailService;
    
    @TransactionalEventListener
    public void onUserCreated(UserCreatedEvent event) {
        // 保证在事务提交后处理
        User user = userRepository.findById(event.getUserId())
            .orElseThrow(() -> new EntityNotFoundException("User not found after TX commit"));
        
        emailService.sendWelcomeEmail(user);
    }
}

五、规避

当在事务方法中涉及异步操作时，问自己：

时序验证：我的MQ消费者是否依赖此事务中创建/修改的数据？
边界识别：事务边界是否恰好包裹了所有数据操作，不包含通信逻辑？
回滚考量：若事务回滚，已发送的MQ消息如何处理？(补偿机制)
重试设计：消费者是否具备幂等性和重试能力，应对短暂不一致？
监控覆盖：是否有监控能检测到"消息先于数据到达"的异常情况？

事务与MQ的协调问题，本质是分布式系统中时空关系的映射。

避免此问题不在于使用更复杂的框架，而在于深刻理解事务边界 、明确系统组件间的时序依赖 ，以及设计符合物理规律的架构。

当你下次在事务方法中编写MQ发送代码时，不妨暂停片刻，思考：此刻，我的数据的确切位置是什么？