消费端ACK与重回队列

最新推荐文章于 2024-02-11 10:23:31 发布
最新推荐文章于 2024-02-11 10:23:31 发布
阅读量460 收藏
点赞数 1
CC 4.0 BY-SA版权
分类专栏： rabbitMQ
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/HNUST_LIZEMING/article/details/94839315

 消费端的手工ACK和NACK（确认·处理失败）

消费端进行消费的时候，如果由于业务异常我们可以进行日志的记录，然后进行补偿

（如果多次nack，我们可以先发送ack 然后日志记录  后面坐人工补偿）——

如果由于服务器宕机等严重问题 那我们需要手工进行ack保障消费成功

 

 

消费端的重回队列

消费端重回队列是为了对没有处理成功的消息，把消息重新会送给broker

一般我们实际应用中 都会关闭重回队列的 也就是设置为flase

就算是重回队列也是回到队列的尾部。 

RabbitMQ高级特性-消费端ACK与重回队列
听雪楼
12-26 2234
消费端ACK与重回队列 消费端ACK 消费端的手工ACK和NACK, ACK是确认成功消费, NACK表示消息处理失败, 会重发消息 消费端进行消费的时候, 如果由于业务异常我们可以进行日志的记录, 然后进行补偿 如果由于服务器宕机等严重问题, 就需要手工进行ACK保障消费端消费成功 重回队列 消费端重回队列是为了对没有处理成功的消息, 把消息重新回递给Broker 一般在实际应用中, 都会...
消费端ACK和消费端限流
白天不懂夜的黑的博客
04-21 434
一.消费端的限流 RabbitMQ提供了一种qos(服务质量保证)功能, 即在非自动确认消息的前提下, 如果一定数目的消息(通过consumer或者channel设置qos的值)未被确认前, 不进行消费新的消息.自动签收要设置成false, 建议实际工作中也设置成false void basicQos(int prefetchSize, int prefetchCount, boolean gl...
RabbitMQ 消费端的ack与重回队列
gpweixing的博客
02-16 510
消费端的ACK与NACK ack：成功处理 nack：处理失败 消费端因为业务异常，我们可以进行日志的记录，然后进行补偿。 由于服务器宕机等严重问题，那我们就需要手工ACK，保障消费端消费成功。 消费端重回队列： 对没有处理成功的消息，会把消息重新递给Broker。 一般不使用重回队列。 生产者代码： package com.example.rabbitmq.limit; import com.rabbitmq.client.Channel; import com.rabbitmq.client.Co
RabbitMQ消息可靠性保证机制3--消费端ACK机制
bug_null的博客
01-07 1638
可以保证数据成功的发送到RabbitMQ，以及持久化机制，然尔这依然无法完全保证整个过程的可靠性，因为如果消息被消费过程中业务处理失败了，但是消息却已经被标记为消费了，如果又没有任何重度机制，那结果基本等于丢消息。由于消息被不断的重新放回队列，而消费者又只有当前这一个，所以，在不断拒收中被放回。从观察到的结果也印证了，反复的被推送，接收的一个过程中，使用命令查看队列的一个消费的情况。通过观察发现，消息已经没有在队列中了，那就是消息已经被丢弃了。在浏览器中访问，同样有66%的概率会被拒绝，仅33%会被确认。
浅谈RabbitMQ消费端ACK和限流
BASK2311的博客
02-11 1215
如上图所示：如果在A系统中需要维护相关的业务功能，可能需要将A系统的服务停止，那么这个时候消息的生产者还是一直会向MQ中发送待处理的消息，消费者此时服务已经关闭，导致大量的消息都会在MQ中累积。如果当A系统成功启动后，默认情况下消息的消费者会一次性将MQ中累积的大量的消息全部拉取到自己的服务，导致服务在短时间内会处理大量的业务，可能会导致系统服务的崩溃。其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 message 从 RabbitMQ 的消息缓存中移除。
RabbitMQ消息模式（消息的ACK与重回队列）
01-07
如果由于服务器宕机等严重问题，那么我们就需要手工进行ACK，保障消费端消费成功，比如我们在消费端调用第三方接口，但这个第三方接口出现了问题导致接口调用失败，这时我们就要使消息重回队列 消费端的重回队列 ...
消息模式 之 消费端限流、消息的ACK与重回队列、TTL消息、死信队列
qq_44641053的博客
12-07 356
消息模式 之 消费端限流、消息的ACK与重回队列、TTL消息、死信队列消费端限流消息的ACK 与 重回队列TTL 消息死信队列 本章知识： 1、消费端限流 2、消息的ACK与重回队列 3、TTL消息 4、死信队列 消费端限流 相关资料： 消息模式 之 消息100%投递、幂等性、Confirm确认消息、Return返回消息、自定义消费者 什么是消费端的限流？ 假设一个场景，首先，我们 RabbitM...
RabbitMQ高级特性-消费端流控服务和ACK重回队列
a898712940的博客
04-26 281
一：消费端限流【流控】 1.1 什么是消费端的限流 假设一个场景，首先，Rabbitmq服务器有上万条未处理的消息，我们随便打开一个消费者客户端，就会出现： 巨大的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多数据！ 1.2 如何做流控 RabbitMQ提供了一种Qos（服务质量控制）功能，即在非自动确认消息的前提下，如果一定数目的消息（通过基于consume或者channel设置Qos的值）未被确认前，不进行消费新的消息。【就是说消息未处理完就不ACK，就不拉后面的消息】 ..
RabbitMQ 消费端限流、重回队列、TTL与死信队列
贵在坚持
09-01 699
RabbitMQ 为了保证消息投递的可靠性，其提供了很多相关的机制来应对各种问题的发生
消息模式2（消费端限流、消息的ACK与重回队列、TTL消息、TTL消息）
qq_43059674的博客
12-07 375
消费端限流 为什么需要消费端的限流？ 假设一个场景，我们Rabbitmq服务器有上万条未处理的消息，我们随便打开一个消费者客户端，会出现这种情况：巨量的消息瞬间全部推送过来，但是我们单个客户端无法同时处理这么多数据!此时很有可能导致服务器崩溃，严重的可能导致线上的故障。 除了这种场景，还有一些其他的场景，比如说单个生产者一分钟生产出了几百条数据，但是单个消费者一分钟可能只能处理60条数据，...
kafka消息队列样例
09-07
kafka消息队列消费者生产者读写样例。Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。
消费端限流、ACK与重回队列
lql_h的博客
03-26 408
限流概念 假设RabbitMQ服务器有上万条未处理的消息，我们随便打开一个消费者客户端，会出现下面情况： 巨量的消息瞬间全部推送过来，但是单个客户端无法同时处理这么多数据 RabbitMQ提供了一种qos（服务质量保证）功能，即在非自动确认消息的前提下，如果一定数据的消息（通过基于consume或者channel设置qos的值）未被确认前，不进行消费新的消息 void BasicQos(u...
rabbitmq消息队列 ack机制(消息确认机制)和消息补偿机制
朝立的博客
06-24 1595
参考:https://blog.youkuaiyun.com/pan_junbiao/article/details/112956537 ack 机制就是消息在 生产者在发布消息以后，消息存在内存中，如果消息被确认就会删除内存中消息。
redis 队列及ACK代码实现
weixin_38917695的博客
06-24 516
redis 队列及ACK代码实现概述流程图代码RedisQueueAbstractAckQueueQueueTrait使用消费者ACK 概述 使用PHP+Redis简单实现一下队列以及ACK，确保服务的可靠性。 流程图 代码 RedisQueueAbstract <?php namespace Redis\Queue; use Redis\Libs\RedisClient; use Redis\Queue\QueueTrait; abstract class RedisQueueAbstrac
RabbitMQ手动ACK与死信队列
菜鸟逆袭之路
05-27 9490
RabbitMQ手动ACK与死信队列
Kafka：消费者消费失败处理-重试队列
程序员无羡的博客
04-02 7901
Kafka：消费者消费失败处理-重试队列
Kafka 延时队列&重试队列
lyl54545的博客
07-06 1286
1. 简介TimingWheel是kafka时间轮的实现，内部包含了⼀个TimerTaskList数组，每个数组包含了⼀些链表组成的TimerTaskEntry事件，每个TimerTaskList表示时间轮的某⼀格，这⼀格的时间跨度为tickMs，同⼀个TimerTaskList中的事件都是相差在⼀个tickMs跨度内的，整个时间轮的时间跨度为interval = tickMs * wheelSize，该时间轮能处理的时间范围在cuurentTime到currentTime + interval之间的事件。
kafka - Consumer 手动acks应答
祁_z
07-16 2961
yaml配置 # 是否自动消费（true=自动应答） enable-auto-commit: false listener: ## 手动提交ack offset模式 ack-mode: manual # kafka spring: kafka: # kafka服务器地址(可以多个) bootstrap-servers: 192.168.2.190:9092 # 配置消费者 consumer: # 指定一个默认的消费者组名 group
Kafka消息重新发送
weixin_30914981的博客
11-05 1637
Kafka消息重新发送 1、 使用kafka消息队列做消息的发布、订阅，如果consumer端消费出问题，导致数据并没有消费，此时不需要担心，数据并不会立刻丢失，kafka会把数据在服务器的磁盘上默认存储7天，或者自己指定有两种方式：1）指定时间，log.retention.hours=168；2）指定大小，log.segment.bytes=1073741824。此时就可以通过重置某个...
RabbitMQ死信队列消费失败导致循环消费
最新发布
08-22
<think>我们正在解决RabbitMQ死信队列消费失败导致的循环消费问题。根据引用[1][2][3][4]中的信息，我们可以总结出以下关键点： 1. 死信队列中的消息来源：消息被拒绝（basic.reject或basic.nack）且requeue=false、消息TTL过期、队列达到最大长度。 2. 问题现象：当死信队列中的消息再次消费失败时，如果没有正确处理，可能会被重新投递到死信队列，形成循环。 3. 循环原因：在默认情况下，如果死信队列的消费者在处理消息时抛出异常，并且配置了重试机制，那么消息可能会被重新投递到死信队列（如果配置不当）。 根据引用[3]中的配置，我们看到在Spring Boot中可以通过以下配置来避免循环： ```yaml rabbitmq: listener: simple: default-requeue-rejected: false # 注意：这里应该设置为false，确保不重新入队 retry: enabled: true max-attempts: 5 initial-interval: 5000 ``` 但是，这个配置是针对业务队列的，它会在业务队列中重试5次，如果仍然失败，就会将消息发送到死信队列（前提是业务队列配置了死信交换机）。 然而，对于死信队列本身，我们同样需要配置消费者，以避免在死信队列中再次消费失败时重新入队。如果死信队列的消费者没有正确配置，那么消费失败的消息可能会被重新放回死信队列，导致循环。 解决思路： 1. **确保死信队列的消费者不重新入队**：当死信队列中的消息消费失败时，我们不应该再将其重新放回队列（包括死信队列和业务队列）。应该将requeue设置为false，并且不再重试（或者有限重试后人工干预）。 2. **为死信队列配置独立的处理逻辑**：死信队列的消息应该由专门的消费者处理，该消费者只负责记录错误、告警和人工干预，而不是尝试重新处理业务。 3. **配置死信队列的消费者不启用重试**：或者设置最大重试次数为0，这样一旦处理失败，消息就会被丢弃（或者进入另一个归档队列，而不是重新入队）。 具体步骤： ### 步骤1：配置业务队列的死信交换机 在声明业务队列时，指定死信交换机和路由键（如果需要）。例如： ```java @Bean public Queue businessQueue() { Map<String, Object> args = new HashMap<>(); args.put("x-dead-letter-exchange", "dlx.exchange"); // 死信交换机名称 args.put("x-dead-letter-routing-key", "dlx.routingkey"); // 死信路由键 return new Queue("business.queue", true, false, false, args); } ``` ### 步骤2：配置死信队列和死信交换机 创建一个死信交换机（通常是直接交换机或主题交换机）和一个死信队列，并将它们绑定。 ### 步骤3：配置死信队列的消费者 为死信队列配置消费者，并确保在消费失败时不会重新入队。在Spring Boot中，我们可以为死信队列单独设置一个监听容器，并配置其重试策略。 我们可以为死信队列的消费者禁用重试，或者设置重试次数为0（即不重试），这样一旦消费失败，消息就会被丢弃（或者记录日志后人工处理）。 在配置文件中，我们可以为死信队列的监听器单独配置，但Spring Boot默认不支持为不同的队列设置不同的重试策略（通过配置文件）。因此，我们可以通过编程方式配置。 例如，为死信队列创建一个独立的监听容器工厂： ```java @Configuration public class RabbitMQConfig { // 业务队列的监听容器工厂，可以配置重试 @Bean public SimpleRabbitListenerContainerFactory businessListenerContainerFactory(ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); // 设置重试 factory.setAdviceChain(retryInterceptor()); return factory; } // 死信队列的监听容器工厂，不重试 @Bean public SimpleRabbitListenerContainerFactory dlqListenerContainerFactory(ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); // 不设置重试拦截器，即不重试 return factory; } private Advice retryInterceptor() { return RetryInterceptorBuilder.stateless() .maxAttempts(5) // 最大尝试次数（包括第一次） .backOffOptions(1000, 2.0, 10000) // 初始间隔，乘数，最大间隔 .build(); } } ``` 然后，在死信队列的监听方法上，指定使用这个不重试的容器工厂： ```java @RabbitListener(queues = "dlq.queue", containerFactory = "dlqListenerContainerFactory") public void handleDlqMessage(Message message) { try { // 处理死信消息，这里一般是记录日志、告警、人工干预等，而不是重试业务 // 如果处理失败，我们不希望重试，所以直接抛出异常，由于没有重试配置，消息会被丢弃（或者根据ack模式确认后丢弃） processDlq(message); } catch (Exception e) { // 记录日志，发送告警 // 然后可以选择重新抛出异常，让消息被丢弃（因为requeue=false）或者不抛出，根据业务决定 // 注意：如果抛出异常，并且没有重试，那么消息会被拒绝且不重新入队（requeue=false） throw e; } } ``` 在死信队列的消费者中，我们不应该进行业务处理，而是进行错误分析、记录和告警。如果需要对死信消息进行重试（比如修复了问题之后），应该由人工介入，将消息重新投递到业务队列。 ### 步骤4：确保死信队列的消息被消费后不再循环 在死信队列的消费者中，如果处理消息时抛出异常，由于我们没有配置重试，并且监听器的默认行为是拒绝消息并且不重新入队（requeue=false），所以消息会被丢弃（如果队列没有设置死信，则消息消失）。为了避免消息丢失，我们可以将死信队列的消息在消费失败后转移到另一个队列（比如“死信归档队列”）或者存储到数据库。 另一种做法是，为死信队列再设置一个死信交换机（即死信队列的死信），指向一个归档队列。这样，如果死信队列的消息被拒绝（消费失败），就会进入归档队列，而不会重新进入死信队列。配置方法类似于业务队列： ```java @Bean public Queue dlqQueue() { Map<String, Object> args = new HashMap<>(); // 设置死信队列的死信交换机 args.put("x-dead-letter-exchange", "dlx.archive.exchange"); return new Queue("dlq.queue", true, false, false, args); } ``` 然后，归档队列只用于存储，不消费，或者由专门的程序消费并持久化存储。 ### 总结配置要点： 1. 业务队列配置死信交换机，当消息在业务队列中重试多次失败后，会进入死信队列。 2. 死信队列的消费者不配置重试，一旦处理失败，消息要么被丢弃，要么进入归档队列（通过为死信队列配置死信交换机）。 3. 死信队列的消费者只做错误记录和告警，不做业务处理。 这样，当死信队列中的消息消费失败时，不会重新进入死信队列，从而避免了循环消费。 ### 引用说明： - 引用[1]：说明死信队列需要谨慎配置和管理。 - 引用[2]：说明死信队列的应用场景和消息进入死信队列的三种情况。 - 引用[3]：展示了在Spring Boot中如何配置业务队列的重试，避免消息直接进入死信队列（通过重试减少进入死信队列的可能）。 - 引用[4]：说明死信交换机的使用和消息消费失败的处理方式（进入死信队列或重新发布）。 通过以上配置，我们可以有效解决RabbitMQ死信队列消费失败导致的循环消费问题。 ### 相关问题： 1. 如何为RabbitMQ死信队列配置独立的消费者？ 2. RabbitMQ中如何设置队列的死信交换机？ 3. 在Spring Boot中如何为不同的队列配置不同的重试策略？ 4. 如何避免RabbitMQ消息循环消费？</think>### 解决RabbitMQ死信队列消费失败导致的循环消费问题 根据您提供的引用资料[^1][^2][^3][^4]，以下是解决RabbitMQ死信队列循环消费问题的完整方案： #### 一、核心问题原因分析 1. **未限制重试机制** 死信队列消费者配置了无限重试或自动重新入队机制[^3] 2. **消息错误重新入队** 消费失败时错误地将消息重新发布到原队列或死信队列自身[^4] 3. **配置不当** `requeue=true` 或未正确设置死信交换机（DLX）[^2][^3] 4. **缺乏隔离机制** 死信队列未与业务队列完全隔离[^1] #### 二、解决方案（基于引用资料） ##### 1. 禁用自动重新入队（关键配置） ```yaml # Spring Boot配置（引用[^3]） rabbitmq: listener: simple: default-requeue-rejected: false # 必须设置为false retry: enabled: true max-attempts: 3 # 限制最大重试次数 initial-interval: 5000 ``` ##### 2. 正确配置死信交换机和路由 ```java // 业务队列声明（引用[^2][^4]） Map<String, Object> args = new HashMap<>(); args.put("x-dead-letter-exchange", "dlx.exchange"); // 死信交换机 args.put("x-dead-letter-routing-key", "dlx.routingkey"); // 死信路由键 channel.queueDeclare("business_queue", true, false, false, args); ``` ##### 3. 死信队列消费端安全处理 ```java // 死信消费者示例（引用[^4]） channel.basicConsume("dlx.queue", false, (consumerTag, delivery) -> { try { // 处理逻辑（必须包含异常捕获） processDLQMessage(delivery.getBody()); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); } catch (Exception e) { // 关键：禁止重新入队 channel.basicReject(delivery.getEnvelope().getDeliveryTag(), false); // 安全处理：归档或人工干预 archiveMessage(delivery.getBody()); alertAdmin(e.getMessage()); // 触发告警 } }); ``` ##### 4. 建立死信处理防火墙 | 组件 | 配置要求 | 作用 | |---------------|----------------------------|-------------------------| | 业务队列 | 设置`x-dead-letter-exchange` | 消息失败时路由到DLX[^2] | | 死信交换机(DLX) | 类型建议`direct`或`topic` | 隔离死信路由[^4] | | 死信队列 | 无特殊参数 | 存储死信消息 | | 死信消费者 | `autoAck=false` + `requeue=false` | 安全消费[^3] | #### 三、防止循环的最佳实践 1. **死信队列只读原则** 死信队列消费者**只允许**： - 记录日志 - 发送告警 - 人工干预处理 **禁止**任何形式的自动重试或重新发布[^1] 2. **三级处理策略** ```mermaid graph LR A[业务队列] -->|消费失败| B(DLX死信交换机) B --> C[死信队列] C --> D{死信消费} D -->|成功| E[归档] D -->|失败| F[人工干预队列] ``` 3. **监控配置（必备）** - 监控死信队列深度：`rabbitmqctl list_queues name messages_ready` - 设置阈值告警：当死信消息 > 10 时触发通知[^1] #### 四、常见错误排查 1. **循环场景** `业务队列 → DLX → 死信队列 → 重新发布 → 业务队列` **修复**：检查是否有代码将死信消息重新发布到原交换机[^4] 2. **配置验证** 执行命令检查队列参数： ```bash rabbitmqctl list_queues arguments name # 应包含：x-dead-letter-exchange ``` 3. **消息轨迹** 启用`rabbitmq_tracing`插件跟踪消息流向，确认是否出现循环路由。 > **关键总结**：死信队列是消息系统的"停尸房"，不是"急诊室"。必须通过`default-requeue-rejected=false` + 人工干预机制打破循环链[^1][^3][^4]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值