【RocketMQ】RocketMQ怎么保证消息不丢失

Mxin5

已于 2025-06-18 16:45:55 修改

阅读量8.8k

点赞数 9

CC 4.0 BY-SA版权

文章标签： java 分布式大数据

于 2022-08-19 16:11:23 首次发布

本文链接：https://blog.csdn.net/m0_64210833/article/details/126426814

本文围绕RocketMQ如何保证消息不丢失展开。在Producer发送阶段，有同步发送、异步发送+重试机制；Broker处理阶段，采用同步刷盘（单体模式）、主从复制模式（同步复制）；Consumer消费阶段，先消费再返回结果，还有消费消息重试机制，同时要保证消费幂等。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Producer发送消息阶段

发送消息阶段涉及到Producer到broker的网络通信，因此丢失消息的几率一定会有，那RocketMQ在此阶段用了哪些方法保证消息不丢失了（或者说降低丢失的可能性）。

同步发送

同步发送时最可靠的发送方式，需要等待broker返回是否收到的响应。

RocketMQ提供了3种发送消息方式，分别是：

同步发送：Producer 向 broker 发送消息，等待 broker 响应ACK给Producer表示发送成功。

异步发送：Producer 首先构建一个向 broker 发送消息的任务，把该任务提交给线程池，等执行完该任务时，回调用户自定义的回调函数，执行处理结果。

单向发送：单项发送方式只负责发送请求，不等待应答，Producer只负责把请求发出去，而不处理响应结果。

我们在调用producer.send方法时，不指定回调方法，则默认采用同步发送消息的方式，这也是丢失几率最小的一种发送方式(但是效率比较低)。

DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName");  
producer.setNamesrvAddr("nameserver:9876");  
producer.start();  

try {  
    Message msg = new Message("TopicTest", "TagA", "Hello RocketMQ".getBytes(RemotingHelper.DEFAULT_CHARSET));  
    SendResult sendResult = producer.send(msg);  
    System.out.printf("消息发送状态: %s%n", sendResult.getSendStatus());  
} catch (Exception e) {  
    e.printStackTrace();  
}

异步发送+重试机制

同步发送消息等待时间过长,效率比较低，采用异步的方式将消息发送到Broker中，通过回调方法来处理发送的结果。如果出现失败，我们通过重试机制（设置重试次数）再次发送。

producer.setRetryTimesWhenSendAsyncFailed(3);  // 设置异步发送失败重试次数  
producer.send(msg, new SendCallback() {  
    @Override  
    public void onSuccess(SendResult sendResult) {  
        System.out.println("消息发送成功");  
    }  
    @Override  
    public void onException(Throwable e) {  
        System.out.println("消息发送异常，准备重试");  
        e.printStackTrace();  
    }  
});

Broker处理消息阶段

同步刷盘（单体模式）

单体模式下，当producer将消息发送到broker当中，broker会将数据存入到内存中之后，立刻刷盘(同步的将内存中的数据持久化到磁盘上)，在保证刷盘成功的前提下响应ACK（成功）消息给Producer。

通过配置broker.conf文件，可以启用同步刷盘

flushDiskType = SYNC_FLUSH

我们知道，当消息投递到broker之后，会先存到内存，然后根据broker设置的刷盘策略是否立即存储到磁盘中，也就是如果刷盘策略为异步，broker并不会等待消息存储到磁盘才返回producer一个成功的消息，也就是说当broker所在的服务器突然宕机，则会丢失部分页的消息。采用同步刷盘的策略，将内存中的数据持久化到磁盘当中后返回给producer一个ACK成功的消息）。

解释：

同步刷盘:当数据写入到内存中之后立刻刷盘(同步的将内存中的数据持久化到磁盘上)，在保证刷盘成功的前提下响应ACK消息给Producer。如果失败了，MQ就会进行一个重试机制。

异步刷盘:数据写入内存后，直接响应ACK消息给Producer。异步将内存中的数据持久化到磁盘上。

主从复制模式（同步复制）

配置主从架构，并设置同步复制：

brokerRole = SYNC_MASTER

即使broker设置了同步刷盘，如果主broker磁盘损坏（单点故障），也是会导致消息丢失。采用主从模式，即使Master Broker节点挂掉，Slave Broker中的数据不会丢失，同时设置master为SYNC_MASTER，然后将slave设置为同步刷盘策略，producer每发送一条消息，都会等消息投递到Broker中主节点和从节点都复制成功了，broker才会当作消息发送成功，从而保证消息不丢失。

Consumer消费消息阶段

consumer采用先消费再返回结果

从producer投递消息到broker，即使前面这些过程保证了消息正常持久化，但如果consumer消费消息没有消费到也算是消息的丢失。

所以Consumer采用先消费再返回结果的方式，Consumer对Broker中消息进行消费完成后，才向Broker返回ack（消费成功的消息--acknowledge）表示成功消费，如果失败则进行重试机制。通过幂等性消费来防止MQ的消费被重复消费。

通常消费消息的ack机制一般分为两种思路：

1、先提交后消费；

2、先消费消息，消费成功后再提交（这个更稳当）；

思路一可以解决重复消费的问题但是会丢失消息，因此Rocketmq默认实现的是思路二，由各自consumer业务方保证幂等（通过给每个消息携带一个唯一标识信息，去数据库进行判断。或者在producer的时候就存储一个唯一标识（消息），消费成功删除redis中的消息确保不被重复消费。）来解决重复消费问题。

消费消息重试机制

当消费消息失败了，Broker会采用重试机制（重试次数、重试间隔等）重新投递消息给消费者，我们只需要保证消费幂等就可以了，保证消息不会被重复消费。

幂等：保证消息不会被重复消费

@Override  
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {  
    for (MessageExt msg : msgs) {  
        String msgId = msg.getMsgId();  
        if (isProcessed(msgId)) {  
            // 消息已处理，直接返回成功  
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;  
        }  
        try {  
            // 处理消息  
            processMessage(msg);  
            // 标记消息为已处理  
            markAsProcessed(msgId);  
        } catch (Exception e) {  
            // 处理失败，返回稍后重试  
            return ConsumeConcurrentlyStatus.RECONSUME_LATER;  
        }  
    }  
    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;  
}