springboot--RabbitMQ消息确认Ack/NAck

最新推荐文章于 2025-03-11 12:59:59 发布

czw_xiaobei

最新推荐文章于 2025-03-11 12:59:59 发布

阅读量829

点赞数

CC 4.0 BY-SA版权

分类专栏： springboot-rabbitmq 文章标签： rabbitmq rabbitmq-ack springboot-rabbitmq

本文链接：https://blog.youkuaiyun.com/czw_xiaobei/article/details/103467293

springboot-rabbitmq 专栏收录该内容

3 篇文章

订阅专栏

本文探讨了消息队列中消息的状态变化与消费机制。详细解释了消息未进行ack操作时的状态为unacked，不能被其他消费者消费，重启consumer后会重新消费；以及消息进行nack操作时，设置requeue为true，消息将回到队列，由其他消费者轮训消费。

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

如果消息未进行ack操作，即忘了ack，那么该消息消费完之后，消息的状态为unacked，该消息也不能被其他消费者所消费；如果重启consumer，该消息将重新被消费。
如果消息进行nack操作，即如下，将第三个参数requeue设置为true，此时消息将重新回到队列，mq将轮训其他的消费者。

channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

czw_xiaobei

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

SpringBoot 整合 RabbitMQ 实现死信队列

死牛胖子的技术随笔

01-09

1750

Springboot 整合RabbitMq ，用心看完这一篇就够了

热门推荐

默默不代表沉默

09-04

50万+

该篇文章内容较多，包括有rabbitMq相关的一些简单理论介绍，provider消息推送实例，consumer消息消费实例，Direct、Topic、Fanout的使用，消息回调、手动确认等。（但是关于rabbitMq的安装，就不介绍了）在安装完rabbitMq后，输入http://ip:15672/，是可以看到一个简单后台管理界面的。在这个界面里面我们可以做些什么？可以手动创建............

参与评论您还未登录，请先登录后发表或查看评论

Springboot+RabbitMQ+ACK机制(生产方确认(全局、局部)、消费方确认)、知识盲区

鸢尾_的博客

08-07

4095

Springboot+RabbitMQ+ACK机制(生产方确认(全局、局部)、消费方确认)、知识盲区

RabbitMQ实现消息可靠投递

baobao的博客

07-08

1326

本文从本人博客搬运，原文格式更加美观，可以移步原文阅读：RabbitMQ实现消息可靠投递实际开发中，我们经常需要保证消息由生产者发送到消费者接收并消费的整个过程中，消息不丢失，这就需要在RabbitMQ中实现消息的可靠投递。主要包含以下两部分：发送端可靠性：指生产者发送消息到RabbitMQ Broker这个过程中保证消息不丢失接收端可靠性：指RabbitMQ Broker将消息发送给消费者并且消费者正确处理消息的这个过程中保证消息不丢失发送端可靠性发送端可靠性主要包含3个方面：消息抵达交

springboot整合rabbitMQ系列6 死信队列演示，消息被拒绝（basicReject/ basicNack）并且不再重新投递到队列时requeue=false

小哇

04-13

1998

先用rabbitmq控制台创建正常的交换机，队列，死信的交换机，队列，绑定关系等，查看以下博文，只要以下文章的1-3步，因为这里演示另种情况，消息到死信队列https://blog.youkuaiyun.com/qq_41712271/article/details/115658848?spm=1001.2014.3001.5501生产者为方便，直接用rabbitmq控制台发送消息创建一个消费者工程，并手动ack确认，部分api的使用可查看以下博文，https://blog.youkuaiyun.com/qq_4171227.

RabbitMQ学习笔记：获取消息（Ack Mode）

OceanSky的专栏

10-26

9961

在服务器端的客户端页面从队列中获取消息是一个危险的动作，生产环境一定要了解业务之后再做操作 Act Mode Nack message requeue true 获取消息，但是不做ack应答确认，消息重新入队 Ack message requeue false 获取消息，应答确认，消息不重新入队，将会从队列中删除 reject requeue true 拒绝获取消息，消息...

SpringBoot + RabbitMQ从延时队列中删除指定的值【RabbitMQ中的basicAck和basicNack的区别以及basicReject又是什么？】

番茄Salad

04-15

4769

业务需求是，就是我本来是有一个order-queue队列绑定到了死信队列交换机order-dead-direct-exchange上，然后我的业务是，现在有一个用户下单但是没有付款，order-queue队列写入该条信息并计时24小时后如果用户还是未付款状态则移除到死信队列order-dead-queue中。问题来了，如果在这个24小时内，用户取消订单，这时候就要从order-queue队列中移除该条信息。怎么操作呢？

RabbitMQ与Spring的框架整合之Spring Boot实战

Biexiansheng的博客

12-11

328

1、RabbitMQ与Spring的框架整合之Spring Boot实战。首先创建maven项目的RabbitMQ的消息生产者rabbitmq-springboot-provider项目，配置pom.xml配置文件，如下所示： 1 <project xmlns="http://maven.apache.org/POM/4.0.0" 2 xmlns:xsi="http://...

SpringBoot基于RabbitMQ实现消息可靠性

时间如瑾代码如诗

07-25

1682

本文详细阐述了RabbitMQ中的消息确认机制、生产者确认配置、publisher-return和ConfirmCallback的实战应用，以及消息持久化策略，包括交换机、队列和消息的持久化。同时介绍了消费者确认模式和失败重试机制，以及如何处理消费者异常和死信消息的优雅方案。

SpringBoot-RabbitMQ篇-消息可靠投递

ITGENIUS1的博客

07-23

648

一、发送者异常监控 1.1 发送者异常种类 1.基本处理流程补偿(兜底)方案 2.模拟broker宕机：修改发送者端口如5673，然后启动，发送消息，端口不对无法连接主机错误信息：java.net.ConnectException: Connection timed out: connect 补偿方案：加入异常处理，如果不可达则返回错误这种错误在发送的时候就已经可以发现，直接将错误返回给调用方即可 @RequestMapping("/direct") public Object sendEma

深度掌握 RabbitMQ 消息确认（ACK）机制，确保消息万无一失

m0_67265654的博客

03-02

794

消息的发布与订阅模式：RabbitMQ 采用发布/订阅模式，生产者将消息发布到交换器（Exchange），交换器根据路由规则将消息路由到相应的队列（Queue），消费者从队列中获取消息并进行处理。交换器（Exchange）和队列（Queue）的工作机制：交换器负责接收生产者发送的消息，并根据路由键将消息路由到一个或多个队列。队列则用于存储消息，等待消费者进行消费。自动 ACK：当消费者从队列中获取消息后，RabbitMQ 会自动将该消息标记为已确认，无需消费者手动进行确认操作。手动 ACK。

项目实战-基于SpringBoot整合RabbitMQ实现延时队列

zhaozhangxiao2的博客

02-21

1440

真正用于项目实战。

SpringBoot整合RabbitMQ

zhuge_long的专栏

04-09

1383

手动ACK:消费者设置了手动ACK机制后，可以显式的提交/拒绝消息(这一步骤叫做发送ACK)，如果消息被消费后正常被提交了ack，那么此消息可以说是流程走完了，然后MQ将此消息从队列中删除。情况3：当i == 5时，也就是给第五条消息设置过期时间是5秒，其它的还是10秒，发现失效，这里要注意一点，由于这条消息发送给队列的时候不是在队列的头部，故不会单独判断，而是和其它队列一样，10秒钟就消失，可以改成i==0，则第一条消息是5秒过期，或者i

springboot整合rabbitMQ系列5 死信列队3种情况演示1 basic.nack 并且不再重新投递 requeue=false 和 2 ttl消息 3 达到队列最大长度三种情况

小哇

04-14

1089

关于死信队列的描述，可查看博文https://blog.youkuaiyun.com/qq_41712271/article/details/115658848?spm=1001.2014.3001.5501 1 application.yml配置文件 server: port: 8021 spring: #给项目来个名字 application: name: rabbitmq-test #配置rabbitMq 服务器 rabbitmq: host: 127.0.0.1 .

Springboot整合RabbitMQ Ack

Nov17的博客

03-08

932

Springboot整合RabbitMQ Ack 一、前言 ack指Acknowledge，确认。表示消费端收到消息后的确认方式。有三种确认方式：自动确认：acknowledge=“none” 手动确认：acknowledge=“manual” 根据异常情况确认：acknowledge=“auto”，（这种方式使用麻烦，不作讲解）其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 message 从 RabbitMQ 的消息缓存中移除。但是在实际业务处理

Acknowledgment.nack方法重试消费kafka消息异常

theflowerofac^MQLYES的专栏

03-11

1030

当BatchAcknowledgingMessageListener批量消费消息时，使用的是ConsumerBatchAcknowledgment，重试时需要告诉ConsumerBatchAcknowledgment要从这批量消息中的哪条开始重试消费，即要指定index值。而使用AcknowledgingMessageListener消费单条消息时，使用的是ConsumerAcknowledgment，重试时它知道重试当前的消息，因为就这一条，所以只需要指定重试时间就可以了。这样的设计也很好理解。

rabbitMQ 中三种常用交换机：direct、topic、fanout的使用以及区别和queue消息的Ack,Nack ,Reject 消息类型

码农崛起

08-10

4766

当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对；生产者将消息不是直接发送到队列，而是发送到X交换机，然后由交换机发送给两个队列，两个消费者各自监听一个队列，来消费消息。生产者，一个队列一个或多个消费者，当多个消费者同时监听一个队列时，他们并不能同时消费一条消息，而是随机消费消息，即一个队列中一条消息，只能被一个消费者消费。如果匹配请求中的值，则向程序返回该响应数据。.......

SpringBoot整合消息中间件 RabbitMQ 第 9 篇 —— 死信队列

流放深圳

04-11

350

死信队列我们先考虑以下场景： 1、RabbitMQ 服务器将消息推送给消费者时，无法得到消费者手动应答，或者是被消费者拒绝消费（basic.reject 或 basic.nack），使用补偿机制后仍然未能被消费，这种情况下 RabbitMQ 为了保证消息不被删除和丢失，应该怎么办？ 2、RabbitMQ 设置消息的过期时间 TTL，当消息到达过期时间后，RabbitMQ 为了保证消息不被删除和丢失，应该怎么办？（比如一些限时活动的公告） 3、高并发下 RabbitMQ 的消息队列已满，无...

rabbitmq java.lang.IllegalStateException: Channel closed; cannot ack/nack

最新发布

03-31

<think>嗯，我现在遇到了RabbitMQ的这个问题，报错是java.lang.IllegalStateException: Channel closed; cannot ack/nack。首先我得弄清楚这个错误的原因。根据用户提供的引用内容，好像是因为配置的问题，特别是当在yml中配置了listener参数，而项目里已经用了SimpleRabbitListenerContainerFactory的话，会导致冲突。还有引用里提到的信道超时关闭，半小时后出现异常，这可能和超时设置有关。那我要怎么解决呢？可能需要检查配置是否有重复，比如在yml里是否不小心配置了listener相关的参数，而实际上已经在代码中通过配置类设置了。然后，关于信道的超时问题，可能需要调整心跳设置或者超时时间，确保连接不会因为空闲太久而被关闭。另外，确认消费者的处理逻辑是否正确，比如是否及时确认消息，避免处理时间过长导致信道关闭。还有，确认是否在代码中正确地处理了异常，比如在信道关闭时是否有重连机制。可能需要查看RabbitMQ客户端的配置，比如是否启用了自动恢复功能。同时，检查网络稳定性，避免因为网络问题导致连接断开。总之，需要从配置、超时设置、消费者逻辑和网络环境几个方面来排查和解决这个问题。</think>### 解决方案：RabbitMQ报错 `java.lang.IllegalStateException: Channel closed; cannot ack/nack` #### 问题分析此错误通常由以下原因导致： 1. **配置冲突**：在项目中已通过 `SimpleRabbitListenerContainerFactory` 配置了监听器参数，但同时在 `yml` 中重复配置了 `listener` 相关属性，导致信道被异常关闭[^1]。 2. **信道超时**：RabbitMQ 默认信道空闲超时时间为 30 分钟，若消费者未及时处理消息或未发送心跳，信道会因超时关闭，后续尝试 `ack/nack` 操作会触发此异常[^2]。 3. **网络或资源问题**：网络波动或消费者处理消息时间过长，导致信道被强制关闭。 --- #### 解决步骤 1. **检查配置冲突** - **删除冗余配置**：若项目中已通过 `@Configuration` 类定义 `SimpleRabbitListenerContainerFactory`，需移除 `yml` 文件中 `spring.rabbitmq.listener` 相关配置。 ```yaml # 错误示例（需删除以下配置） spring: rabbitmq: listener: simple: acknowledge-mode: auto ``` 2. **调整信道超时设置** - **显式设置超时时间**：在 `yml` 中配置信道超时和心跳检测，避免默认值导致意外关闭。 ```yaml spring: rabbitmq: connection-timeout: 5000 # 连接超时时间（毫秒） requested-heartbeat: 60 # 心跳间隔（秒） ``` - **配置容器工厂**：在 `SimpleRabbitListenerContainerFactory` 中设置 `idleEventInterval`，定期检测空闲信道。 ```java @Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory(ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setIdleEventInterval(30000L); // 30秒检测一次空闲状态 return factory; } ``` 3. **优化消费者逻辑** - **及时处理消息**：确保消费者逻辑不会长时间阻塞，避免因处理超时导致信道关闭。 - **手动确认模式**：使用 `MANUAL` 或 `AUTO` 确认模式时，需在代码中正确调用 `channel.basicAck` 或 `channel.basicNack`。 ```java @RabbitListener(queues = "myQueue") public void handleMessage(String message, Channel channel, @Header(AmqpHeaders.DELIVERY_TAG) long tag) { try { // 处理消息逻辑 channel.basicAck(tag, false); // 手动确认 } catch (IOException e) { // 异常处理 } } ``` 4. **启用自动恢复机制** - 在连接工厂中配置自动恢复，避免因网络波动导致信道不可用。 ```yaml spring: rabbitmq: connection-factory: recovery-enabled: true # 启用自动恢复 ``` --- #### 验证方法 1. 运行消费者服务，观察日志中是否仍有 `Channel closed` 异常。 2. 使用 RabbitMQ 管理界面检查信道存活时间和心跳状态。 3. 模拟网络中断，验证自动恢复机制是否生效。 ---