关于 RabbitMQ 中 consumer 侧的 ack 属性分析

最新推荐文章于 2024-04-30 17:23:44 发布
最新推荐文章于 2024-04-30 17:23:44 发布
阅读量2.7k 收藏
点赞数
分类专栏： mq 文章标签： consumer侧的ack
http://my.oschina.net/moooofly/blog/143883

      熟悉 RabbitMQ 的人肯定知道  no_ack 属性是在调用 Basic.Consume 方法时可以设置的一个重要参数。本文主要针对 no_ack 设置的两种情况，通过抓包分析的形式讲解下实际应用中的异同，并总结一下相关的处理经验。

============ 我是分隔线 =============
      no_ack 的用途：确保 message 被 consumer “成功”处理了。这里“成功”的意思是，（在设置了 no_ack=false 的情况下）只要 consumer 手动应答了 Basic.Ack ，就算其“成功”处理了。

情况一：no_ack=true （此时为自动应答）
      在这种情况下，consumer 会在接收到 Basic.Deliver + Content-Header + Content-Body 之后，立即回复 Ack 。而这个 Ack 是 TCP 协议中的 Ack 。此 Ack 的回复不关心 consumer 是否对接收到的数据进行了处理，当然也不关心处理数据所需要的耗时。

图1：（Producer+Consumer）


图2：（Consumer）

图3：（Producer）


情况二：no_ack=false （此时为手动应答）
      在这种情况下，要求 consumer 在处理完接收到的 Basic.Deliver + Content-Header + Content-Body 之后才回复 Ack 。而这个 Ack 是 AMQP 协议中的 Basic.Ack 。此 Ack 的回复是和业务处理相关的，所以具体的回复时间应该要取决于业务处理的耗时。
图4：（Producer+Consumer）


图5：（Consumer）


图6：（Producer）


总结：
  • Basic.Ack 发回给 RabbitMQ 以告知，可以将相应 message 从 RabbitMQ 的消息缓存中移除。
  • Basic.Ack 未被 consumer 发回给 RabbitMQ 前出现了异常，RabbitMQ 发现与该 consumer 对应的连接被断开，之后将该 message 以轮询方式发送给其他 consumer （假设存在多个 consumer 订阅同一个 queue）。
  • 在 no_ack=true 的情况下，RabbitMQ 认为 message 一旦被 deliver 出去了，就已被确认了，所以会立即将缓存中的 message 删除。所以在 consumer 异常时会导致消息丢失。
  • 来自 consumer 侧的 Basic.Ack 与 发送给 Producer 侧的 Basic.Ack 没有直接关系。


============ 我是分隔线 =============

最后贴上自己改造的、基于 libevent 实现的 rabbitmq-c 的测试打印。

情况一： 
[warn] evsignal_init: socketpair: No error
drive_machine: [conn_init]  ---  in TCP 3-way connecting!
drive_machine: [conn_connecting]  ---  connection timeout 1 time on socket(6040)
drive_machine: [conn_connected]  ---  connected on socket(6040)

6040: conn_state change   connected ==> snd_protocol_header
  --> Send Protocol.Header!
6040: conn_state change   snd_protocol_header ==> rcv_connection_start_method
  <-- Recv Connection.Start Method frame!
6040: conn_state change   rcv_connection_start_method ==> snd_connection_start_rsp_method
  --> Send Connection.Start-Ok Method frame!
6040: conn_state change   snd_connection_start_rsp_method ==> rcv_connection_tune_method
  <-- Recv Connection.Tune Method frame!
6040: conn_state change   rcv_connection_tune_method ==> snd_connection_tune_rsp_method
  --> Send Connection.Tune-Ok Method frame!
6040: conn_state change   snd_connection_tune_rsp_method ==> snd_connection_open_method
  --> Send Connection.Open Method frame!
6040: conn_state change   snd_connection_open_method ==> rcv_connection_open_rsp_method
  <-- Recv Connection.Open-Ok Method frame!
6040: conn_state change   rcv_connection_open_rsp_method ==> snd_channel_open_method
  --> Send Channel.Open Method frame!
6040: conn_state change   snd_channel_open_method ==> rcv_channel_open_rsp_method
  <-- Recv Channel.Open-Ok Method frame!
6040: conn_state change   rcv_channel_open_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Queue Declaring!
6040: conn_state change   idle ==> snd_queue_declare_method
  --> Send Queue.Declare Method frame!
6040: conn_state change   snd_queue_declare_method ==> rcv_queue_declare_rsp_method
  <-- Recv Queue.Declare-Ok Method frame!
6040: conn_state change   rcv_queue_declare_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Queue Binding!
6040: conn_state change   idle ==> snd_queue_bind_method
  --> Send Queue.Bind Method frame!
6040: conn_state change   snd_queue_bind_method ==> rcv_queue_bind_rsp_method
  <-- Recv Queue.Bind-Ok Method frame!
6040: conn_state change   rcv_queue_bind_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Basic QoS!
6040: conn_state change   idle ==> snd_basic_qos_method
  --> Send Basic.Qos Method frame!
6040: conn_state change   snd_basic_qos_method ==> rcv_basic_qos_rsp_method
  <-- Recv Basic.Qos-Ok Method frame!
6040: conn_state change   rcv_basic_qos_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Basic Consuming!
6040: conn_state change   idle ==> snd_basic_consume_method
  --> Send Basic.Consume Method frame!
6040: conn_state change   snd_basic_consume_method ==> rcv_basic_consume_rsp_method
  <-- Recv Basic.Consume-Ok Method frame!
6040: conn_state change   rcv_basic_consume_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Start waiting to recv!
6040: conn_state change   idle ==> rcv_basic_deliver_method
drive_machine: wait for Basic.Deliver method another 10 seconds!!
drive_machine: wait for Basic.Deliver method another 10 seconds!!

  <-- Recv Basic.Deliver Method frame!
6040: conn_state change   rcv_basic_deliver_method ==> rcv_basic_content_header
  <-- Recv Content.Header frame!
6040: conn_state change   rcv_basic_content_header ==> rcv_basic_content_body
  <-- Recv Content.Body frame!
Content Body is [Hello World betty].
@@@ CB: body len : [17]    body : [Hello World betty]
6040: conn_state change   rcv_basic_content_body ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Start waiting to recv!
6040: conn_state change   idle ==> rcv_basic_deliver_method
drive_machine: wait for Basic.Deliver method another 10 seconds!!
drive_machine: wait for Basic.Deliver method another 10 seconds!!

情况二： 
[warn] evsignal_init: socketpair: No error
drive_machine: [conn_init]  ---  in TCP 3-way connecting!
drive_machine: [conn_connecting]  ---  connection timeout 1 time on socket(6040)
drive_machine: connected on socket(6040)
6040: conn_state change   connected ==> snd_protocol_header
  --> Send Protocol.Header!
6040: conn_state change   snd_protocol_header ==> rcv_connection_start_method
  <-- Recv Connection.Start Method frame!
6040: conn_state change   rcv_connection_start_method ==> snd_connection_start_rsp_method
  --> Send Connection.Start-Ok Method frame!
6040: conn_state change   snd_connection_start_rsp_method ==> rcv_connection_tune_method
  <-- Recv Connection.Tune Method frame!
6040: conn_state change   rcv_connection_tune_method ==> snd_connection_tune_rsp_method
  --> Send Connection.Tune-Ok Method frame!
6040: conn_state change   snd_connection_tune_rsp_method ==> snd_connection_open_method
  --> Send Connection.Open Method frame!
6040: conn_state change   snd_connection_open_method ==> rcv_connection_open_rsp_method
  <-- Recv Connection.Open-Ok Method frame!
6040: conn_state change   rcv_connection_open_rsp_method ==> snd_channel_open_method
  --> Send Channel.Open Method frame!
6040: conn_state change   snd_channel_open_method ==> rcv_channel_open_rsp_method
  <-- Recv Channel.Open-Ok Method frame!
6040: conn_state change   rcv_channel_open_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Queue Declaring!
6040: conn_state change   idle ==> snd_queue_declare_method
  --> Send Queue.Declare Method frame!
6040: conn_state change   snd_queue_declare_method ==> rcv_queue_declare_rsp_method
  <-- Recv Queue.Declare-Ok Method frame!
6040: conn_state change   rcv_queue_declare_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Queue Binding!
6040: conn_state change   idle ==> snd_queue_bind_method
  --> Send Queue.Bind Method frame!
6040: conn_state change   snd_queue_bind_method ==> rcv_queue_bind_rsp_method
  <-- Recv Queue.Bind-Ok Method frame!
6040: conn_state change   rcv_queue_bind_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Basic QoS!
6040: conn_state change   idle ==> snd_basic_qos_method
  --> Send Basic.Qos Method frame!
6040: conn_state change   snd_basic_qos_method ==> rcv_basic_qos_rsp_method
  <-- Recv Basic.Qos-Ok Method frame!
6040: conn_state change   rcv_basic_qos_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Basic Consuming!
6040: conn_state change   idle ==> snd_basic_consume_method
  --> Send Basic.Consume Method frame!
6040: conn_state change   snd_basic_consume_method ==> rcv_basic_consume_rsp_method
  <-- Recv Basic.Consume-Ok Method frame!
6040: conn_state change   rcv_basic_consume_rsp_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Start waiting to recv!
6040: conn_state change   idle ==> rcv_basic_deliver_method
drive_machine: wait for Basic.Deliver method another 10 seconds!!
drive_machine: wait for Basic.Deliver method another 10 seconds!!
drive_machine: wait for Basic.Deliver method another 10 seconds!!

  <-- Recv Basic.Deliver Method frame!
6040: conn_state change   rcv_basic_deliver_method ==> rcv_basic_content_header
  <-- Recv Content.Header frame!
6040: conn_state change   rcv_basic_content_header ==> rcv_basic_content_body
  <-- Recv Content.Body frame!
Content Body is [Hello World betty].
@@@ CB: body len : [17]    body : [Hello World betty]
6040: conn_state change   rcv_basic_content_body ==> snd_basic_ack_method
  --> Send Basic.Ack Method frame!
6040: conn_state change   snd_basic_ack_method ==> idle

drive_machine: [conn_idle]  ---  [CONSUMER]: Start waiting to recv!
6040: conn_state change   idle ==> rcv_basic_deliver_method
drive_machine: wait for Basic.Deliver method another 10 seconds!!
drive_machine: wait for Basic.Deliver method another 10 seconds!!
aosica
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
rabbitmq ACK消费者确认机制
qq_42572322的博客
09-07 826
生产者可靠性投递消息后，消费者也可能会产生一些问题，比如：没有接受到消息，接收消息后在代码执行过程中出现了异常等。在这种情况下我们需要进行额外的处理，那么就需要手动进行消息的确认签收，rabbitmq给我们提供了一个机制：ACK机制。额外的知识：RabbitMQ的死信队列详解 - 简书 (jianshu.com) ACK机制有三种方式： 自动确认 acknowledge="none" 手动确认 acknowledge="manual" 根据异常情况来确认（暂时不怎么用) acknowledge="a
RabbitMQ-Consumer Ack消息的可靠性
下雨了亦留此地的博客
09-07 153
文章目录消费端收到消息后的确认方式手动确认方式的测试消息可靠性要点 消费端收到消息后的确认方式 ack指Acknowledge，确认。表示消费端收到消息后的确认方式。 有三种确认方式: 自动确认: acknowledge=“none” 手动确认: acknowledge=“manual” 根据异常情况确认: acknowledge=“auto” 其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应message 从 RabbitMQ的消息缓存中移除。但是在实际业务处理中，很可能
RabbitMQ高级特性------Consumer Ack
每周更新，热爱coding！
04-12 192
这种处理方式不安全，因为消息被接受了但是业务没有处理成功，那么就会造成消息丢失。所以在业务中，我们最好选用手动确认的方式，以免发生问题，导致消息丢失。接收到，那么则自动确认收到，并将相应的。也是同样的，需要先设置相应的属性。消息队列，消息队列，消息队列！如果没有被接收到，调用。”，自动确认是指消息一旦被。
RabbitMQ之消费者ACK 功能
最新发布
CSDN_LiMingfly的博客
04-30 1652
若 RabbitMQ 服务器端一直没有收到消费者的确认信号，并且消费此消息的消费者已经断开连接， 则服务器端会安排该消息重新进入队列，等待投递给下一个消费者（也可能还是原来的那个消费者）。可以看到当前队列中的 “Ready” 状态和 “Unacked” 状态的消息数，分别对应等待投递给消费者的消息数和已经投递给消费者但是未收到确认信号的消息数。对于手动确认的方式，RabbitMQ Broker 将消息发送给 Consumer 之后，由 Consumer 手动确认之后，才任务消息投递成功。
RabbitMQ：消费者ACK机制、生产者消息确认
m0_48325361的博客
03-09 4124
文章目录一、RabbitMQ 高级特性基础案例环境搭建：环境：1. 生产者发送消息确认1.1 confirm 确认模式1.2 return 退回模式源代码1.1.3 小结2. 消费者签收消息(ACK)2.1 代码实现源代码 一、RabbitMQ 高级特性 基础案例环境搭建： 基础环境搭建(手把手教你环境搭建和五种工作模式)：https://blog.csdn.net/m0_48325361/article/details/123174843?spm=1001.2014.3001.5502 环境： 队列：
12-RabbitMQ高级特性-Consumer ACK
DevOps海洋的渔夫@专栏
10-05 1197
12-RabbitMQ高级特性-Consumer ACKConsumer Ackack指Acknowledge，确认。 表示消费端收到消息后的确认方式。有三种确认方式：自动确认：acknowledge="none"手动确认：acknowledge="manual"根据异常情况确认：acknowledge="auto"，（这种方式使用麻烦，不作讲解）“其中自动确认是指，当消息一旦被Consumer接...
SpringBoot+RabbitMQ实现手动Consumer Ack
LoveLacie的博客
04-08 2674
@[TOC](目录) 一、Consumer Ack的三种方式 (1)、自动确认：acknowledge = “none”,这是默认的方式,如果不配置的话,默认就是自动确认,消费方从消息队列中拿出消息后,消息队列中都会清除掉这条消息(不安全). (2)、手动确认：acknowledge = “manual”,手动确认就是当...
rabbitmq消费者获取消息慢_rabbitMQ 消息模型和ACK消息确认机制
weixin_30133813的博客
02-04 1008
简单队列helloworld.png官方介绍：RabbitMQ是一个消息代理：它接受和转发消息。 你可以把它想象成一个邮局：当你把邮件放在邮箱里时，你可以确定邮差先生最终会把邮件发送给你的收件人。 在这个比喻中，RabbitMQ是邮政信箱，邮局和邮递员。RabbitMQ与邮局的主要区别是它不处理纸张，而是接受，存储和转发数据消息的二进制数据块。P(producer/ publisher)：生产者，...
RabbitMQ 消费者确认（Consumer Acknowledgements)
Lamb_IT的博客
11-03 3327
RabbitMQ关于数据安全有两个特性：[发布者确认(Publisher Confirms](https://blog.csdn.net/Lamb_IT/article/details/102649484))和消费者确认(Consumer Acknowledegements)。前者用于MQ服务器(broker)告诉发布者传递消息的结果，它是消息协议的拓展内容；后者用于消费者告诉MQ服务器消息传递的结果，是消息协议包含的定义。本文主要介绍RabbitMQ对消费者确认的实现。
RabbitMQ之Consumer
jannal专栏
10-06 6075
文章目录RabbitMQ-java-client版本Consumer推拉模式代码消息确认与拒绝prefetch关闭 RabbitMQ-java-client版本 com.rabbitmq:amqp-client:4.3.0 RabbitMQ版本声明: 3.6.15 Consumer RabbitMQ的消费模式分为两种:Push(服务端推)和Pull(客户端拉)，Push(推)采用Basic...
Rabbitmq- 消费者ack机制与发布者消息确认
程序员路同学
11-13 2915
RabbitMq消息ack机制与confirm确认/return返回
RabbitMQ 高级特性 Consumer Ack
weixin_42947972的博客
03-29 401
RabbitMQ 高级特性 Consumer Ack
rabbitMQ的消费者消息确认机制的说明 Consumer ACK
weixin_44605216的博客
08-09 251
## rabbitMQ如何保证消息被消费者成功消费？ 前面我们讲了生产者发送确认机制和消息的持久化存储机制，然而这依然无法完全保证整个过程的 可靠性，因为如果消息被消费过程中业务处理失败了但是消息却已经出列了（被标记为已消费了），我 们又没有任何重试，那结果跟消息丢失没什么分别。 RabbitMQ在消费端会有Ack机制，即消费端消费消息后需要发送Ack确认报文给Broker端，告知自 己是否已消费完成，否则可能会一直重发消息直到消息过期（AUTO模式）。 这也是我们之前一直在讲的“最终一致性”、“可恢复.
RabbitMQ高级特性——超详细说明Consumer Ack（消费者端消息确认，附代码）
保暖透气大裤衩LeoLee的博客
11-07 2769
大伙可以到我的RabbitMQ专栏获取更多信息 demo示例这里拿 概述 上一篇文章RabbitMQ高级特性——消息的可靠投递（confirm模式与return模式）中介绍了RabbitMQ提供的两种保证消息投递可靠性的方式： confirm确认模式 return 退回模式 这两种方式实质上是提供了对消息生产者侧的消息可靠性保证，保证了生产者的消息能正确的进入预期的队列中。本文将介绍一下Consumer Ack，这是一种面向消费者的消息可靠性保证方案。 Consumer Ack ack——ac
rabbitmq消息可靠性--------Consumer Ack(消费者确认机制)（一）
weixin_43811057的博客
03-23 4295
文章预览：Consumer Ack(消费者确认机制)springBoot完整案列1. pom.xml2.yml3.主入口类4.rabbitConfig5.MessageListener5.2 @RabbitListener(queues = "q.biz", ackMode = "MANUAL") Consumer Ack(消费者确认机制) 如何保证消息被消费者成功消费？ 生产者发送确认机制和消息的持久化存储机制，然而这依然无法完全保证整个过程的可靠性，因为如果消息被消费过程中业务处理失败了但是消息却已经
RabbitMQ高级特性——Consumer Ack（2020年7月27日）
weixin_44376261的博客
07-28 613
ack指Acknowledge，确认。 表示消费端收到消息后的确认方式。 有三种确认方式： 自动确认：acknowledge=“none” 手动确认：acknowledge=“manual” 根据异常情况确认：acknowledge=“auto”，（这种方式使用麻烦，不作讲解） 其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 message 从 RabbitMQ 的消息缓存中移除。 但是在实际业务处理中，很可能消息接收到，业务处理出现异常，那么该消息就会丢失。 如果设置了手动
10 RabbitMQ 高级特性ConsumerAck、TTL、DLX
weixin_68930048的博客
12-11 166
RabbitMQ 高级特性ConsumerAck、TTL、DLX
RabbitMQ（三）消费端ack机制
JavaTeachers的博客
10-14 840
ACK机制 什么是消息确认ACK 如果在处理消息的过程中，消费者的服务器在处理消息的时候出现异常，那么可能这条正在处理的消息就没有完成消息消费，数据就会丢失。为了确保数据不会丢失，RabbitMQ支持消息确定-ACK。 ACK的消息确认机制 ACK机制是消费者从RabbitMQ收到消息并处理完成后，反馈给RabbitMQ，RabbitMQ收到反馈后才将此消息从队列中删除。 如果一个消费者在处理消息出现了网络不稳定、服务器异常等现象，那么就不会有ACK反馈，RabbitMQ会认为这个消息没有正常消费，会将消息
RabbitMQ养成记 （8. 消费者接受消息可靠性 consumer Ack）
陆续将以前写过的技术博客统一搬运到csdn
05-16 875
而不使用注解的情况下，需要显式实现MessageListener接口并重写onMessage方法，是一种传统的方式来定义 RabbitMQ 的消息监听器。而使用@RabbitListener注解的方式，是Spring AMQP提供的一种更简化和方便的方式，用于声明消息监听器的方法。使用@RabbitListener注解的方法不需要显式实现MessageListener接口，是因为框架会自动处理消息的转换，并将消息内容作为方法的参数传递进去。然后我们把原来的代码扩充一下 在这里实现 手动的ack。
rabbitmq手动ack代码
09-05
要实现RabbitMQ的手动ack（acknowledge）代码，您可以按照以下步骤进行操作： 1. 首先，在RabbitMQ配置文件或者使用代码配置的方式中，设置`acknowledge="manual"`，表示使用手动确认模式。 2. 创建一个消费者类（比如MqConsumer），并实现接口ChannelAwareMessageListener，该接口中有一个方法onMessage用于接收消息。 3. 在onMessage方法中，处理接收到的消息，并在处理完成后调用channel.basicAck方法来手动确认消息的消费。 例如，可以在onMessage方法中的代码如下所示： ```java @Override public void onMessage(Message message, Channel channel) throws Exception { try { // 处理接收到的消息 // ... // 手动确认消息的消费 channel.basicAck(message.getMessageProperties().getDeliveryTag(), false); } catch (Exception e) { // 发生异常时可以选择进行消息的拒绝或者重新投递 // ... } } ``` 4. 如果在处理消息时发生异常，您可以选择进行消息的拒绝或者重新投递，这取决于您的业务需求。 请注意，在手动确认模式下，如果消费者未调用channel.basicAck方法确认消息消费，消息将会一直保留在RabbitMQ的消息缓存中，直到消费者重新连接或者超时。因此，在实现手动ack代码时，确保正确处理消息的消费以及异常情况的处理是非常重要的。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [rabbitmq自动及手动ACK](https://blog.csdn.net/qq_18671415/article/details/115349452)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_1"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值