MQ消息队列

原创已于 2025-06-05 09:38:16 修改 · 654 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#java #中间件 #分布式

于 2025-01-02 14:05:19 首次发布

消息队列专栏收录该内容

1 篇文章

订阅专栏

微服务开发中经常会使用消息队列进行跨服务通信。在一个典型场景中，服务A执行一个业务逻辑，需要保存数据库，然后通知服务B执行相应的业务逻辑。在这种场景下，我们需要考虑如何发送消息。

基于消息队列，生产者发送消息到消费者消费消息的过程：

生产者发送消息

MQ收到消息并将数据持久化，在存储中新增一条记录

返回ACK给生产者

MQ 推送消息给对应的消费者，等待消费者返回ACK

如果消费者在指定时间内成功返回ACK，那么MQ则认为消费成功，执行第6步删除消息，如果MQ在指定时间内没有收到ACK，则认为消息消费失败，会重新推送消息，重复执行第4、5、6步操作。

删除消息。

1 基础版

首先，我们可能会考虑将数据库操作和消息发送放在同一个事务中，以下是伪代码示例：

@Transactional  
public void saveWithMessage(BusinessDO businessDO){ 
 String id = IdUtils.nextId();
 businessDO.setId(id);
    xxxRepository.save(businessDO);  
    
    BusinessMessage businessMessage = new BusinessMessage();  
    businessMessage.setKey(id);  
    SendResult send = rocketMQTemplate.syncSend("test-topic", sendMessage);
}

在这段代码里通过@Transactional注解将数据库的操作以及发送消息放到一个事务中，如果数据库的保存或者消息发送失败，则回滚事务。

1.1 缺陷

1.1.1 数据不一致

这种消息发送方式无法保证数据的最终一致性。

假设数据库处理成功，消息消费成功，但是MQ由于某些原因处理超时，导致ACK确认失败，此时整个事务回滚，结果出现数据不一致问题。

这种数据不一致的问题在RPC调用的场景下也经常出现，其根本的原因在于：远程调用，结果最终可能为成功、失败、超时；而对于超时的情况，处理方最终的结果可能是成功，也可能是失败，调用方是无法知晓的。

1.1.2 事务未提交

其次，使用以上方式还存在另一个问题，即消费者在处理消息时可能读不到刚刚保存的数据，即消费者消费速度快于事务提交的速度。

举例：

假设服务B需要通过消息中的数据ID获取服务A数据库保存的数据。这种情况下，数据库操作与消息发送在同一事务中。可能出现服务B在处理消息时，服务A事务还未提交，导致服务B获取的数据是空数据，无法执行相应业务逻辑。

1.1.3 适用场景

尽管这种发送方式存在上述两个问题，但在某些场景下仍然适用。例如，消费者在处理时不依赖生产者的数据，且对数据一致性要求不高，这种情况下消息发送和数据库保存可以不在同一个事务中。

2 进阶版

为解决事务未提交问题，我们可以确保事务提交后再发送消息。在SpringBoot项目中，有两种常见解决方案。

2.1 事务同步器

基于事务同步器的方法：

@Transactional  
public void saveWithMessage(BusinessDO businessDO){  
    xxxRepository.save(businessDO);  
    
    TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {  
        @Override  
        public void afterCommit() {  
            BusinessMessage businessMessage = new BusinessMessage();  
            businessMessage.setXXX();  
            rocketMQTemplate.syncSend("test-topic", sendMessage);  
        }  
    });  
}

TransactionSynchronizationManager.registerSynchronization 是 Spring 框架中用于注册事务同步的方法。通过这个方法，你可以在事务提交、回滚或完成时执行一些额外的逻辑。

在上述代码中，使用了afterCommit方法，在事务成功提交后执行发送消息操作，确保在数据库操作成功且事务稳定的情况下发送消息。

2.2 消息监听器

另一种方法是基于ApplicationEventPublisher，在保存数据库操作后发布一个事件，并通过@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)注解监听事件。这样可以确保消息在数据库事务提交之后再发送。

@Transactional  
public void saveWithMessage(BusinessDO businessDO){  
    xxxRepository.save(businessDO);  

 eventPublisher.publishEvent(new UserCreatedEvent(registerUser));
}

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 
public void handleUserRegisteredEvent(UserCreatedEvent userCreatedEvent) {  
    rocketMQTemplate.syncSend("test-topic", sendMessage);  
}

这里需要说明一下：在默认情况下Spring的事件监听机制并不是异步的，而是同步的将代码进行解耦，@TransactionalEventListener也是通过同步的方式，但是加入了回调的方式来解决，这样就能够控制事务进行Commited、Rollback时才进行事件的处理，来达到事务同步的目的。

2.3 适用范围

通过以上方式，相较于基础版，可以确保消息在事务提交后发送，解决了消费者读取空数据的问题。但仍然无法保证数据的一致性，适用于对数据一致性要求不高的场景。

3 本地消息表+补偿重试

如果需要保证最终一致性而非强一致性，可以采用本地消息表+补偿重试的方式来发送消息。

这种方式的执行原理如下：

在执行业务操作的同时，在本地消息表中插入一条状态为待发送的记录，业务数据的记录与消息记录必须在同一个事务中完成，这是此方案的核心原则。由于消息表与业务表在同一个库中，事务可以通过数据库来保证。

事务提交后发送消息，如果消息发送成功，则将消息状态标记为发送成功或删除消息

在生产者服务中会创建一个定时任务，定时从消息表中检索待发送的消息重新发送。

对于消费者消费失败，则依赖MQ本身的重试机制来完成，保证数据的最终一致性。

核心代码如下：

@Transactional  
public void saveWithMessage(BusinessDO businessDO){  
    TransactionMessage transactionMessage = new TransactionMessage();  
    transactionMessage.setStaus(MessageStatus.WAITING_SEND);  
    transactionMessage.setMessageKey(businessDO.getId());  
    ...  
  
    xxxRepository.save(businessDO);  
    messageRepository.save(TransactionMessage);  
    TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {  
        @Override  
        public void afterCommit() {  
            messageService.sendMessage(transactionMessage,businessDO);  
        }  
    });  
}  

public void sendMessage(TransactionMessage transactionMessage,BusinessDO businessDO){  
    BusinessMessage businessMessage = new BusinessMessage();  
    businessMessage.setXXX();  
    try{  
        rocketMQTemplate.syncSend("test-topic", sendMessage);  
        transactionMessage.setStatus(MessageStatus.SUCCESS);  
        messageRepository.update(transactionMessage);  
    }catch (Exception e){  
        // 执行失败的业务逻辑  
    }  
  
}