MQ常见问题梳理

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

#rocketmq

MQ 如何保证消息不丢失

哪些环节可能导致消息丢失

  • 生产者向主节点发送消息
  • 主节点向从节点同步消息
  • MQ 数据持久化
  • 消费者消费消息
生产者发送消息如何保证不丢失

生产者发送消息丢失的原因是因为网络的不稳定性。

  • RocketMQ 通过同步和异步发送消息机制来保证发送消息的安全性。

同步：消息最安全，但是效率很低。
异步：消息安全和效率之间比较均衡，但会加大客户端的负担。因为消息发送后还要维护回调上下文，网络 IO 和内存负担会更高。

  • RocketMQ 独有的事务消息机制也可以保证生产者安全发送消息
  • kafka 也提供了类似的同步，异步发送消息机制。
  • RabbitMQ 的 Publisher Confirms 生产者确认机制的思路也是 Publisher 收到 Broker 的响应后在执行对应的回调方法。

统一的思路是，给生产者响应，让生产者知道消息是否发送成功。

Broker写入数据如何保证不丢失

Producer 把消息发送给 Broker 后，消息会先写入到 Page Cache 缓存中，过一段时间再写入磁盘。如果写入磁盘之前断电，这些数据就丢失了。

  • RocketMQ 通过配置参数支持同步刷盘和异步刷盘，同步刷盘也不是来一条数据刷一次，而是隔 10ms 刷一次，异步是隔 200ms。
  • kafka 默认由系统控制刷盘时间。
  • RabbitMQ 也是由系统控制刷盘时间，但是官方建议使用 Publisher Confirms 来确保消息安全。
Broker 主从同步如何保证不丢失

RocketMQ 主从集群
主节点和从节点都是确定的，如果主节点挂了，从节点也不会转化为主节点。所以这种方式主从同步不会丢失数据。

Deldger 高可用集群
基于 Raft 协议进行主从同步，使用多数派同意机制才可以将数据保存，保证集群内数据的一致性，但是不保证数据不丢失。虽然可能因为网络分区造成的脑裂问题使数据丢失，但是这个可能性很小。

kafka 集群
当主节点挂了，从节点会重新选取主节点，这时旧的主节点可能还有没有同步成功的数据，当旧的主节点恢复正常，发现集群里有主节点，会自动转化为从节点，并主动删除多余数据，这样那些还未同步的数据就丢失了。

消费者消费消息如何不丢失

一般的 MQ 产品都设置了消费者状态确认机制，如果消费者没有成功消费消息，Broker 会重新发送消息，因此，消费者消费消息还是比较安全的。

但是如果异步处理消息，就可能造成消息丢失。


MQ 如何保证消息的顺序性

  • RocketMQ 将同一组消息放入同一个 MessageQueue 中。消费者锁定一个队列读取全部的消息之后再读取另一个队列。
  • kafka 消费者是单线程模式，生产者按序将消息放入队列中，消费者就可以按序读取消息。
  • RabbitMQ 在一个队列对应一个消费者的时候可以保证，但一个队列对应多个消费者不可以保证。

MQ 如何保证消息幂等性

生产者处理方式

  • RocketMQ 在发送消息时，给每条消息分配一个唯一 ID。通过这个 ID，判断消息是否重复投递。
  • kafka 可以通过打开幂等性配置来保证。

消费者处理方式

  • RocketMQ 使用 key 属性存放唯一 ID，不依赖默认的唯一 ID。

MQ 如何快速处理积压的消息，

  • 对于RabbitMQ，如果是 Classic Queue经典对列，针对同一个 Queue，直接加更多的Consumer实例就可以了。
  • 对于RocketMQ，增加的 Consumer 实例最多也只能和 Topic 下的 MessageQueue 个数相同，因此不可以使用增加 Consumer 的方法。

如果要快速处理积压的消息，可以创建一个新的Topic，配置足够多的MessageQueue。然后把Consumer实例的Topic转向新的Topic，并紧急上线一组新的消费者，只负责消费旧Topic中的消息，并转存到新的Topic中。这个速度明显会比普通Consumer处理业务逻辑要快很多。然后在新的Topic上，就可以通过添加消费者个数来提高消费速度了。之后再根据情况考虑是否要恢复成正常情况。

MQ 消息中间件梳理
wgchen
04-19 370
MQ 消息中间件梳理
大厂消息中间件高频面试题与知识点整理（RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ）
热门推荐
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
04-07 172万+
互联网高频面试之消息中间件基本问题和知识点整理分析
MQ_常见问题
Chill Lyn
06-01 1809
文章目录应用场景选型高可用RabbitMQ镜像集群模式Kafka重复消费接口幂等强校验弱校验消息丢失RabbitMQ生产者在消息传入过程中数据丢失RabbitMQ消息丢失消费者消息丢失顺序消费问题解决消息堆积过期失效 应用场景 - 异步处理： - 应用解耦： - 流量削峰： 选型 吞吐量：ActiveMQ和RabbitMQ都是万级，RocketMQ和Kafka是十万级 时效性：Rabbit是微秒级，其他是毫秒级 可用性：ActiveMQ和RabbitMQ是主从架构，RocketMQ和Kafka是
MQ常见问题分析
最新发布
IAtlantiscsdn的博客
09-18 622
本章节主要分析一些Rocketmq常见消息丢失问题。
MQ相关常见问题集锦(FRQ)
05-16
MQ相关常见问题集锦(FRQ)
mq常见问题
qq_38639813的博客
07-11 992
1、消息丢失：可能发消息时没发成功、rabbitmq服务器出问题、消费者接到消息但没处理完报错等。启用confirm、return、ack模式、消息补偿 2、rabbitmq防止重复处理：因为网络原因，消费者本身已经接到消息了，但是没有及时给rabbitmq发确认消息，导致mq消息没删除继续往消费者端发送同样的消息。利用redis做修改记录（setnx），当每次操作发现有修改记录了，说明处理重复了 3、消息堆积：就是消费者消费速度远远小于生产者生产速度。可以合理的设置消费者服务的并发量、限流和加服务器来解决
MQ常见问题
weixin_39480141的博客
08-22 939
mq主要问题就是消息丢失，重复消费，顺序性等问题，像消息丢失，常见的可能是发送的时候丢失，或者队列丢失，或者消费失败，导致丢失。顺序消费很常见，举个例子，比如先新增，后删除的消息，这种就需要保证顺序消费，造成mq不顺序消费的原因有三个，最常见的是多个消费者并行处理，大家都消费同一消息队列的消息，如果没有特殊的限制，就会造成消息的处理顺序可能会与发送顺序不一致，另外一种就是分区机制，不同的分区内的消息顺序可能会被打乱，还有就是重试，如果消息处理失败时，重试机制重发可能产生影响。在kafka中配置重试机制。
CSP认证流程解析及常见问题梳理
[CSP认证流程解析及常见问题梳理](https://img-blog.csdnimg.cn/20201210122557412.PNG?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81MTM2ODc2...
MQ 常见使用场景全解析
weixin_57681114的博客
08-14 767
消息中间件（MQ）在分布式系统中发挥关键作用，主要应用于七大场景：1）异步解耦，实现系统间松耦合与异步通信；2）流量削峰，应对突发高并发；3）延迟消息，精准触发定时任务；4）分布式事务，保障数据最终一致性；5）日志收集，高效处理海量日志；6）任务分发，提升批量处理效率；7）并行任务，加速大规模任务执行。这些场景覆盖了系统解耦、性能优化、时序控制等核心需求，能有效提升系统稳定性与扩展性，是构建高可用分布式架构的重要工具。
RocketMQ常见面试题及答案梳理
qq_38038507的博客
01-19 2177
半消息是只生产者向broker发送消息时，还没经过两次确认的消息，此时的状态标记为“不可消费”状态，所以暂时对消费者不可见9.消息的可用性，RocketMQ如何能保证消息的可用性/可靠性？当一条消息无法正常消费的时会被投递到死信队列，比如一条消息初次消费失败或超时，消息队列会自动进行消费重试累计默认16次；达到最大重试次数后，消息队列不会立刻将消息丢弃而是暂时存放到死信队列中。死信队列的特征死信消息会保存三天后（CommitLog的过期时间）被删除。
MQ常见问题及解决方案
u012454084的博客
04-14 4720
MQ常见问题及解决方案
activemq常见问题汇总
qq_30162239的博客
03-12 597
请参考连接：http://blog.youkuaiyun.com/u010310183/article/details/51683141
RabbitMQ——常见问题（笔记）
weixin_46949627的博客
09-01 2727
rabbitMQ常见问题处理
MQ（消息队列）常见问题即及解决方案
qq_50847694的博客
04-14 3290
MQ消息队列中，常见的问题：消息丢失、消息重复消费、消息顺序错乱、消息堆积、高可用性不足、事务消息一致性。
rabbit-mq 常见问题
kuangvquanshui的博客
12-19 4425
1. connection error; protocol method: #method(reply-code=530, reply-text=NOT_ALLOWED - access to vhost '/' refused for user 'springcloud', class-id=10, method-id=40) 说明：账户springcloud没有对 “/” 的权限，在 mq
Mq 如何处理幂等问题方案
08-21
<think>嗯，用户想了解消息队列中实现幂等性的解决方案。这个问题很实用，因为在实际分布式系统中，消息重复消费是个常见痛点。 用户可能是个后端开发工程师，正在设计一个需要高可靠性的系统。从ta直接问"解决方案"的措辞看，应该已经理解了幂等性的概念，现在需要落地实践层面的指导。考虑到消息队列的复杂性，ta可能还隐含了对方案选择成本、适用场景的考量。 先梳理核心问题点：消息重复产生的场景主要有三个——生产者重发、MQ主从切换、消费者超时未确认。对应的解决方案需要分层处理。 生产者的幂等性可以通过消息ID+服务端去重实现。比如RocketMQ的MessageID或业务唯一键，配合Broker的缓存校验。不过要注意时效性，永久存储所有消息ID不现实，通常结合滑动时间窗口。 消费者的方案更关键，因为最终业务逻辑在这里执行。主流的三种方案各有优劣：唯一键约束适合写操作，状态机对流程型业务友好，而版本号控制更通用但实现略复杂。用户可能需要根据业务类型选择，比如支付订单用唯一键，库存扣减用版本号。 全局ID服务虽然可靠，但会引入额外组件，中小型系统可能更倾向使用数据库现有机制。另外要注意分布式锁的方案，它本质是串行化处理，在高并发场景要谨慎评估性能。 用户可能没意识到的是，幂等性设计需要业务逻辑配合。比如退款操作天然是幂等的，但创建订单就不是。这点在方案选型时要重点说明。 最后考虑补充些工程实践细节：比如Redis的原子操作要设合理过期时间，数据库唯一键冲突的优雅处理，以及如何设计降级方案。这些在实际编码中都是关键点。 相关问题的延伸很必要，因为用户接下来很可能面临具体实现问题。比如Kafka和RocketMQ的机制差异，或者如何测试幂等性，这些都应该包含在后续问题里。</think>在消息队列中实现**幂等性**的核心在于确保同一条消息被多次消费时，业务状态不会产生错误变更。以下是分层解决方案及实践思路： --- ### **一、幂等性破坏的常见场景** 1. **生产者重发**：网络超时导致生产者重复发送消息（如MQ未及时响应ACK） 2. **Broker主从切换**：未同步的消息因故障转移被重新投递 3. **消费者处理失败**：消费后未及时ACK，MQ重新投递（如消费者崩溃或网络抖动）[^4] --- ### **二、幂等性解决方案** #### **(1) 生产者端控制** - **方案：消息唯一标识 + Broker去重** - 为每条消息附加**全局唯一ID**（如业务ID+时间戳+随机数） - Broker端缓存已接收消息ID（如Redis或本地缓存），拦截重复消息 ```java // 示例：RocketMQ 生产者幂等 Message msg = new Message("Topic", "Tag", "KEY_20230801001", body.getBytes()); producer.send(msg); // Broker通过KEY去重 ``` > **适用场景**：MQ原生支持去重（如RocketMQ的Message Key机制）[^1] #### **(2) 消费者端控制（核心方案）** | **方案** | **实现逻辑** | **适用场景** | |------------------------|-----------------------------------------------------------------------------|--------------------------| | **唯一键约束** | 消费前校验数据库唯一键（如订单ID），存在则拒绝操作 | 创建类业务（订单、支付） | | **状态机驱动** | 基于业务状态流转（如"已支付"状态订单不再处理扣款） | 流程型业务（退款、审核） | | **版本号/乐观锁** | 更新数据时携带版本号：`UPDATE table SET val=new_val, version=version+1 WHERE id=1 AND version=old_version` | 更新类业务（库存扣减） | | **分布式锁拦截** | 对业务ID加锁（如Redis SETNX），确保单线程处理 | 高并发敏感操作 | ```java // 示例：使用Redis分布式锁实现消费幂等 public void consume(Message msg) { String bizId = msg.getKey(); if (redis.setnx("LOCK:" + bizId, "1", 30)) { // 尝试加锁 try { if (checkDuplicate(bizId)) { // 检查是否已处理 process(msg); // 执行业务逻辑 markProcessed(bizId); // 标记已处理（如写DB） } } finally { redis.del("LOCK:" + bizId); // 释放锁 } } } ``` > **关键点**： > - 唯一键/状态机方案需与业务强耦合 > - 分布式锁需设置合理超时时间，避免死锁 > - 版本号控制是数据库层通用方案[^3] #### **(3) 全局ID服务** - **独立生成全局流水号**（如雪花算法、UUID） - 消费前查询**去重表**（存储已处理ID），原子性插入与业务处理需在同一事务 ```sql START TRANSACTION; INSERT INTO idempotent_records (msg_id, status) VALUES ('MSG_001', 'PROCESSING'); -- 插入去重表 UPDATE orders SET amount = amount - 100 WHERE order_id = 1001; -- 业务操作 COMMIT; ``` --- ### **三、方案选型建议** | **场景** | **推荐方案** | |-----------------------------|--------------------------------| | 简单写操作（如新增记录） | 数据库唯一索引约束 | | 更新操作（如账户扣款） | 乐观锁+版本号 | | 复杂业务流程（多步骤事务） | 状态机+分布式事务 | | 高频请求（如秒杀） | Redis原子操作+过期时间 | --- ### **四、注意事项** 1. **去重存储时效性**：根据业务设置缓存/表记录的保留时间（如支付业务保留24小时） 2. **锁粒度控制**：分布式锁的Key需精确到业务ID，避免锁竞争瓶颈 3. **最终一致性**：去重标记写入与业务操作需保持原子性（或补偿机制）[^2] 4. **MQ自身特性利用**：如Kafka的`enable.idempotence=true`、RocketMQ的`MessageKey`去重 > 幂等性本质是**业务逻辑问题**，需结合具体场景设计。例如： > - 支付结果通知：使用支付流水号作为唯一键 > - 库存扣减：版本号+条件更新（`UPDATE stock SET count=count-1 WHERE count>=1`）[^3] ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值