聊聊MQ，如何避免消息丢失？如何避免重复消费？

最新推荐文章于 2025-01-12 11:00:00 发布
原创 最新推荐文章于 2025-01-12 11:00:00 发布 · 4.9k 阅读 · 48 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#后端 #java #数据库 #springboot

本文探讨了如何避免使用RabbitMQ时的消息丢失，包括持久化和confirm机制，以及它们在高并发下的局限性。同时，提出了利用数据库事务来增强消息的可靠性。在避免消息重复消费方面，介绍了幂等性的概念，并提出状态判断法和业务判断法作为解决方案。

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

前言

我在工作中，使用到消息中间件MQ的业务还是挺多的，我从事在一家交通行业的公司，业务中经常会涉及处理一些违法数据的场景，项目中经常会使用到RabbitMQ，今天想跟大家聊聊怎样避免消息丢失和重复消费是问题。

在我们发生消息的时候，如果MQ服务器突然宕机了会出现什么情况？是不是我们发过去的消息全部没有了吗？

是的，一般MQ中间件为了提高系统的吞吐量会把消息保存在内存中，如果不作其他处理，MQ服务器一旦宕机，消息将全部丢失。这个是业务不允许的，造成很大的影响。

在遇到这种问题的时候，一般有以下几种处理方式。

如何避免消息丢失

持久化

RabbitMQ中发消息的时候会有个durable参数可以设置，设置为true，就会持久化。

这样的话MQ服务器即使宕机，重启后磁盘文件中有消息的存储，这样就不会丢失了吧。是的这样就一定概率的保障了消息不丢失。

但还会有个场景，就是消息刚刚保存到MQ内存中，但还没有来得及更新到磁盘文件中，突然宕机了。这个场景在持续的大量消息投递的过程中

最低0.47元/天 解锁文章
MQ怎么保证消息不丢失?
a88137的博客
05-16 1230
在我们做业务时候很多时候需要用到消息队列，那消息队列中是怎么保证消息的可靠性的？我们今天学习目前主流的消息队列是怎么保证消息可靠性？
Mq保证数据不丢失
最新发布
chenxuefeng_accp的专栏
06-06 1050
MQ（消息队列）在分布式系统中承担着等重要角色，其中“数据不丢失”是其最关键的可靠性保障之一。下面我将从四个层面为你详细讲解“MQ 如何保证消息不丢失”。
MQ如何确保消息的不丢失？
weixin_43634399的博客
04-09 2022
MQ如何确保消息的不丢失？ 消息持久化 ACK 确认机制 死信队列 消息重试机制 镜像队列
MQ是如何保证消息不丢失的,你这样回答面试官一定说I Want U
weixin_39555954的博客
03-09 6865
目录 序言 RocketMQ RabbitMQ Kafka 序言 又到了金三银四的找工作阶段，你一定被问过MQ是如何保证消息可靠性的或者MQ是如何保证消息不丢失的。我们都知道MQ发送消息一般分为三个阶段分别是生产者发送消息到MQ、MQ存储消息到内存或者硬盘，消费者消费消息。但是这三个过程都有可能因为种种原因导致消息丢失。例如在生产者发送阶段，这个阶段可能由于网络延迟导致mq消息丢失；存储阶段，Broker将消息先放到内存，然后再根据刷盘策略持久化到硬盘上，但是刚收到消息，还没持久化.
如何保证Mq消息不丢失
959
05-12 4639
mq: rabbitmq, rocketmq, kafka
MQ如何保证消息不丢失？
myStyle的博客
02-05 9969
不能少，就是说不能丢失数据。而且持久化可以跟生产的confirm机制配合起来，只有消息持久化到了磁盘之后，才会通知生产者ack，这样就算是在持久化之前rabbitmq挂了，数据丢了，生产者收不到ack回调也会进行消息重发。消费者消费到了这个数据，然后消费后自动提交了offset，让kafka知道你已经消费了这个消息，当你准备处理这个消息时，自己挂掉了，那么这条消息就丢了。主要是因为消费者消费时，刚消费到，还没有处理，结果消费者就挂了，这样你重启之后，rabbitmq就认为你已经消费过了，然后就丢了数据。
MQ如何保证消息不丢失
qq_44027353的博客
02-01 2257
就比如Producer生产一个消费发送到了A节点，这个时间集群中各个节点是不同步消息的，Consumer却在B节点上消费这条消息，这个时候才会把A节点的消息同步到B节点来 再进行消费。会造成消费时消息丢失才场景是：Consumer消费消息变为异步的方式，刚开始收到需要消费的消息就往MQ发送一个消息，然后再去执行本地事务，这个时候如果本地事务执行失败，可是发送给MQ的确认消息却已经发送成功了，这就造成了消费端消息丢失。MQ再判断本地事务的执行结果，如果还是未知就继续重复执行5~7步，默认会重复执行15次。
MQ那点破事，消息丢失、重复消费、消费顺序、堆积、事务、高可用....
公众号：微观技术
12-19 6047
大家好，我是 Tom哥~马上要开启国庆小长假了，祝大家节日快乐，吃喝玩乐走起~为了便于大家查找问题，了解全貌，整理个目录，我们可以快速全局了解关于消息队列，面试官一般会问哪些问题。本篇文章的目录：消息队列的应用场景？答案：1、异步处理  2、流量削峰填谷  3、应用解耦  4、消息通讯异步处理。将一个请求链路中的非核心流程，拆分出来，异步处理，减少主流程链路的处理逻辑，缩短RT，提升吞吐量。如：注册新用户发短信通知。削峰填谷。避免流量暴涨，打垮下游系统，前面会加个消息队列，平滑
消息队列使用中防止消息重复消费的深度剖析
恩爸编程
01-12 1456
在分布式系统借助消息队列实现异步处理、解耦模块时，消息重复消费是个棘手难题。不同的消息队列产品有着各异的特性与机制，下面就结合 Kafka、RabbitMQ、ActiveMQ、RocketMQ 来聊聊如何攻克这一难关。
MQ消息丢失，消息一致性，重复消费解决方案
m0_67402914的博客
06-06 132
大家好，我是Leo。这是开端的第三次循环了。当前正在正处于RocketMQ基础原理。3万字聊聊什么是RocketMQ（一）4万字聊聊阿里二面，保证你看不完聊聊Redis面试题2万字聊聊什么是秒杀系统（中）3万字聊聊什么是Redis（完结篇）3万字聊聊什么是MySQL（初篇）我们在使用MQ在解决实际业务场景中的问题时，往往伴随诸多问题！比如如下图上述两种可能都会导致数据不一致，在业务系统中是 致命的问题！这个时候我们就要保证事务消息。要不全部成功，要不全部失败。来达到订单服务，购物车服务的数据一致性！对于购物
聊聊 MQ 技术选型
Cr1556648487的博客
09-23 1391
”发布和订阅记录流，类似于消息队列或企业消息系统；具有容错能力，且可以持久化的方式存储记录流；当记录流产生时（发生时），可及时对其进行处理。建立实时流数据管道，在系统或应用之间可靠地获取数据；建立对数据流进行转换或反应的实时流应用程序。kafka 包含四种核心 API。Producer API：基于该 API，应用程序可以将记录流发布到一个或多个 Kafka 主题（Topics）；Consumer API：基于该 API，应用程序可以订阅一个或多个主题，并处理主题对应的记录流；
如何保证MQ不丢失信息
weixin_35755188的博客
02-17 1145
为了保证消息队列(MQ)不丢失信息，有以下几种方法可以考虑： 增加冗余：通过将数据存储到多个不同的地方来防止数据丢失。 使用持久化存储：通过将数据存储到磁盘上，而不是内存中，以确保数据不会丢失。 引入数据备份：定期对数据进行备份，以防止意外数据丢失。 使用可靠传输协议：使用可靠的协议，例如 TCP，来保证消息的可靠传输。 引入确认机制：在发送和接收的消息中使用确认机制，以确保消息已被正确...
MQ如何保证消息不丢
weixin_39513464的博客
11-17 354
1. MQ中有生产者确认机制，提供publish confirm来避免消息发送到MQ过程中丢失。当publisher成功发送消息到队列中之后，MQ会提供ack回执给publisher，来保证消息的成功送达。其中publish-confirm代表从生产者到交换机， publish-return代表从交换机到队列。支持消费者确认机制， 消费者处理消息之后向MQ发送ack回执，MQ收到ack之后删除该消息。持久化配置包含：交换机持久化，队列持久化， 消息持久化。生产者-> 交换机-> 队列 -> 消费者。
RocketMQ如何保证消息的不丢失
炭烤玛卡巴卡的博客
10-31 3687
以下防止丢失的方案，都是以增加集群负载，降低吞吐为代价的。这必然会造成集群效率下降。
mq避免重复消费
03-13
### 如何在消息队列 (MQ) 中防止重复消费的最佳实践和解决方案 为了有效应对消息队列中的重复消费问题，通常需要从业务逻辑层面和技术实现两个方面入手。以下是几种常见的方法及其具体实施方式： #### 1. **幂等性设计** 幂等性是指对于同一操作多次执行所产生的影响与一次执行的影响相同。在消息队列中，可以通过唯一标识符来判断某条消息是否已经被成功处理过。 - 使用全局唯一的 `Message ID` 或者自定义的业务键（如订单号），将其存储在一个去重表或者缓存中。 - 在每次接收到新消息时，先查询该消息是否已经存在。如果不存在，则记录下来并继续处理；如果已存在，则忽略这条消息。 这种方法依赖于数据库或分布式缓存（如 Redis）来保存状态信息[^3]。 ```python import redis def process_message(message_id, message_data): r = redis.StrictRedis(host='localhost', port=6379, db=0) if not r.exists(message_id): # 判断是否存在 # 处理业务逻辑 handle_business_logic(message_data) # 记录消息ID到Redis r.setex(message_id, 86400, "processed") # 设置过期时间为一天 else: print(f"Duplicate message detected: {message_id}") ``` --- #### 2. **事务型消息机制** 某些高级消息队列（如 RocketMQ 和 Kafka）提供了事务型消息的支持。这种机制允许生产者在发送消息的同时开启一个本地事务，并等待消费者确认后再提交或回滚事务。 - 生产者发送半消息（Prepared Message），此时消息处于未完成状态。 - 消费者接收消息后返回 ACK/NACK 反馈给生产者。 - 如果反馈为 ACK，则生产者正式提交消息；如果是 NACK 或超时无响应，则丢弃或重新投递消息。 此外，在网络异常情况下，可能会触发补偿机制以确保最终一致性。 --- #### 3. **优化负载均衡策略** 部分消息队列（如 RocketMQ）支持基于特定字段（例如订单号）进行分区路由。这样可以保证具有相同特征的消息总是进入相同的队列，从而减少因乱序引发的重复消费风险。 下面是一个简单的例子展示如何配置 RocketMQ 的顺序消息功能[^2]: ```java // 发送顺序消息 DefaultMQProducer producer = new DefaultMQProducer("example_group"); producer.start(); String orderId = "order_123"; Message msg = new Message("TopicTest", ("Hello RocketMQ").getBytes()); msg.putUserProperty("ORDER_ID", orderId); producer.send(msg, new MessageQueueSelector() { @Override public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) { String id = (String)arg; int index = Math.abs(id.hashCode()) % mqs.size(); return mqs.get(index); } }, orderId); // 将订单号作为参数传递用于选择队列 ``` --- #### 4. **日志审计与监控报警** 建立完善的日志体系可以帮助快速定位潜在的重复消费问题。同时配合实时告警工具（如 Prometheus + Grafana），当检测到异常频率增加时及时通知运维人员介入排查。 日志应至少包含以下几类关键信息： - 消息唯一标识 (`Message ID`) - 接收时间戳 - 执行结果（成功/失败） --- #### 5. **客户端限流控制** 对频繁请求的服务接口设置速率限制器（Rate Limiter），即使发生少量重复调用也不会造成严重后果。例如 Guava 提供了一个简单易用的令牌桶算法实现[^4]。 ```java import com.google.common.util.concurrent.RateLimiter; public class RateLimitedService { private static final double QPS_LIMIT = 10; // 每秒最多允许10次访问 private static final RateLimiter rateLimiter = RateLimiter.create(QPS_LIMIT); public void performOperation() { if (!rateLimiter.tryAcquire()) { throw new RuntimeException("Exceeded allowed operation limit!"); } // 实际业务逻辑... } } ``` --- ### 总结 以上提到的方法各有侧重，实际应用过程中可以根据具体的业务需求灵活组合使用。其中最核心的思想还是围绕着**幂等性保障**展开，辅之以合理的架构设计以及必要的技术手段共同构建起一套健壮可靠的消息处理流程。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值