springboot--RabbitMQ消息确认Ack/NAck

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

#rabbitmq #rabbitmq-ack #springboot-rabbitmq

本文探讨了消息队列中消息的状态变化与消费机制。详细解释了消息未进行ack操作时的状态为unacked，不能被其他消费者消费，重启consumer后会重新消费；以及消息进行nack操作时，设置requeue为true，消息将回到队列，由其他消费者轮训消费。
  1. 如果消息未进行ack操作，即忘了ack，那么该消息消费完之后，消息的状态为unacked，该消息也不能被其他消费者所消费；如果重启consumer，该消息将重新被消费。
  2. 如果消息进行nack操作，即如下，将第三个参数requeue设置为true，此时消息将重新回到队列，mq将轮训其他的消费者。
channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
Springboot 整合RabbitMq ，用心看完这一篇就够了
默默不代表沉默
09-04 50万+
该篇文章内容较多，包括有rabbitMq相关的一些简单理论介绍，provider消息推送实例，consumer消息消费实例，Direct、Topic、Fanout的使用，消息回调、手动确认等。 （但是关于rabbitMq的安装，就不介绍了） 在安装完rabbitMq后，输入http://ip:15672/，是可以看到一个简单后台管理界面的。 在这个界面里面我们可以做些什么？ 可以手动创建............
Springboot+RabbitMQ+ACK机制(生产方确认(全局、局部)、消费方确认)、知识盲区
鸢尾_的博客
08-07 4162
Springboot+RabbitMQ+ACK机制(生产方确认(全局、局部)、消费方确认)、知识盲区
springboot整合rabbitMQ系列6 死信队列演示，消息被拒绝（basicReject/ basicNack）并且不再重新投递到队列时requeue=false
小哇
04-13 2085
先用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 1万+
在服务器端的客户端页面从队列中获取消息是一个危险的动作，生产环境一定要了解业务之后再做操作 Act Mode Nack message requeue true 获取消息，但是不做ack应答确认，消息重新入队 Ack message requeue false 获取消息，应答确认，消息不重新入队，将会从队列中删除 reject requeue true 拒绝获取消息，消息...
RabbitMQ实现消息可靠投递
baobao的博客
07-08 1377
本文从本人博客搬运，原文格式更加美观，可以移步原文阅读：RabbitMQ实现消息可靠投递 实际开发中，我们经常需要保证消息由生产者发送到消费者接收并消费的整个过程中，消息不丢失，这就需要在RabbitMQ中实现消息的可靠投递。主要包含以下两部分： 发送端可靠性：指生产者发送消息到RabbitMQ Broker这个过程中保证消息不丢失 接收端可靠性：指RabbitMQ Broker将消息发送给消费者并且消费者正确处理消息的这个过程中保证消息不丢失 发送端可靠性 发送端可靠性主要包含3个方面： 消息抵达交
SpringBoot + RabbitMQ从延时队列中删除指定的值【RabbitMQ中的basicAck和basicNack的区别以及basicReject又是什么？】
番茄Salad
04-15 4879
业务需求是，就是我本来是有一个order-queue队列绑定到了死信队列交换机order-dead-direct-exchange上，然后我的业务是，现在有一个用户下单但是没有付款，order-queue队列写入该条信息并计时24小时后如果用户还是未付款状态则移除到死信队列order-dead-queue中。问题来了，如果在这个24小时内，用户取消订单，这时候就要从order-queue队列中移除该条信息。怎么操作呢？
【RabbitMQ】-----详解RabbitMQ高级特性之消息确认机制
最新发布
mr_yuanshen的博客
09-10 1332
此时我们可以看到，消费消息时发生异常，导致消息没有被正常消费，而且此时控制台不断地打印日志，deleverTag的值不断增加，观察控制界面可以看到队列中始终有一条消息，是因为AUTO机制下，如果消费消息时发生异常，此时消费方不会确认消息，此时消息就会重新入队，直到消费方能够正常消费消息而不发生异常。这种模式下, 消息⼀旦投递给消费者, 不管消费者是否成功处理了消息, RabbitMQ 就会⾃动确认消息, 从RabbitMQ队列中移除消息. 如果消费者处理消息失败, 消息可能会丢失.
RabbitMQ ACK/NACK机制解析
JavaCodePro的博客
08-22 862
在分布式系统中，消息队列扮演着至关重要的角色，它能够有效地解耦生产者和消费者，提高系统的可用性和伸缩性。然而，在实际应用中，如何确保消息的可靠传递和处理成为一个关键问题。这就引出了RabbitMQ中的ACK/NACK机制，它是保证消息传递可靠性的核心知识点。想象一个场景，在一个复杂的电商系统中，订单服务需要处理大量的订单消息。如果订单服务在处理消息时突然崩溃，而消息没有被正确处理，那么可能会导致订单数据丢失或重复处理。为了防止这种情况发生，我们需要引入一种机制来确保消息在传递过程中能够被正确地确认和处理。
SpringBoot基于RabbitMQ实现消息可靠性
时间如瑾 代码如诗
07-25 1843
本文详细阐述了RabbitMQ中的消息确认机制、生产者确认配置、publisher-return和ConfirmCallback的实战应用，以及消息持久化策略，包括交换机、队列和消息的持久化。同时介绍了消费者确认模式和失败重试机制，以及如何处理消费者异常和死信消息的优雅方案。
RabbitMQ与Spring的框架整合之Spring Boot实战
Biexiansheng的博客
12-11 344
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
zhuge_long的专栏
04-09 1444
手动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 1123
关于死信队列的描述，可查看博文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 956
Springboot整合RabbitMQ Ack 一、前言 ack指Acknowledge，确认。 表示消费端收到消息后的确认方式。 有三种确认方式： 自动确认：acknowledge=“none” 手动确认：acknowledge=“manual” 根据异常情况确认：acknowledge=“auto”，（这种方式使用麻烦，不作讲解） 其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 message 从 RabbitMQ 的消息缓存中移除。但是在实际业务处理
Acknowledgment.nack方法重试消费kafka消息异常
theflowerofac^MQLYES的专栏
03-11 1244
当BatchAcknowledgingMessageListener批量消费消息时， 使用的是ConsumerBatchAcknowledgment，重试时需要告诉ConsumerBatchAcknowledgment要从这批量消息中的哪条开始重试消费，即要指定index值。而使用AcknowledgingMessageListener消费单条消息时，使用的是ConsumerAcknowledgment，重试时它知道重试当前的消息，因为就这一条，所以只需要指定重试时间就可以了。这样的设计也很好理解。
SpringBoot 整合 RabbitMQ 实现死信队列
死牛胖子的技术随笔
01-09 1777
相关知识 什么是死信队列 “死信”是RabbitMQ中的一种消息机制，当你在消费消息时，如果队列里的消息出现以下情况： 消息被否定确认，使用 channel.basicNack 或 channel.basicReject ，并且此时requeue 属性被设置为false。 消息在队列的存活时间超过设置的TTL时间。 消息队列的消息数量已经超过最大队列长度。 那么该消息将成为“死信”，“死信”消...
rabbitMQ 中三种常用交换机：direct、topic、fanout的使用以及区别和queue消息的Ack,Nack ,Reject 消息类型
码农崛起
08-10 5063
当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对；生产者将消息不是直接发送到队列，而是发送到X交换机，然后由交换机发送给两个队列，两个消费者各自监听一个队列，来消费消息。生产者，一个队列一个或多个消费者，当多个消费者同时监听一个队列时，他们并不能同时消费一条消息，而是随机消费消息，即一个队列中一条消息，只能被一个消费者消费。如果匹配请求中的值，则向程序返回该响应数据。.......
SpringBoot整合消息中间件 RabbitMQ 第 9 篇 —— 死信队列
流放深圳
04-11 377
死信队列 我们先考虑以下场景： 1、RabbitMQ 服务器将消息推送给消费者时，无法得到消费者手动应答，或者是被消费者拒绝消费（basic.reject 或 basic.nack），使用补偿机制后仍然未能被消费，这种情况下 RabbitMQ 为了保证消息不被删除和丢失，应该怎么办？ 2、RabbitMQ 设置消息的过期时间 TTL，当消息到达过期时间后，RabbitMQ 为了保证消息不被删除和丢失，应该怎么办？（比如一些限时活动的公告） 3、高并发下 RabbitMQ 的消息队列已满，无...
日常记录-SpringBoot整合RabbitMQ第四节（消费者确认）
会走的鱼
08-07 1246
如果出现异常，就给RabbitMQ返回nack消费失败。实际开发中，比较优雅的一个方案是RepublishMessageRecoverer，将失败消息重新投递到一个专门用于存储异常消息的队列中，等待后续人工处理。开发人员在处理完业务后，调用RabbitMQ封装好的API，向RabbitMQ返回ack确认消费成功或者消费失败。在刚刚的本地重试中，在达到最大次数后，消息会被丢弃，这是Spring内部机制决定的。这样就实现了异常消息重试耗尽后，就会投递到指定的异常队列中去，等待人工处理了。
rabbitmq java.lang.IllegalStateException: Channel closed; cannot ack/nack
03-31
2. **信道超时**：RabbitMQ 默认信道空闲超时时间为 30 分钟，若消费者未及时处理消息或未发送心跳，信道会因超时关闭，后续尝试 `ack/nack` 操作会触发此异常[^2]。 3. **网络或资源问题**：网络波动或消费者处理...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值