RabbitMQ的ack和nack机制

这篇具有很好参考价值的文章主要介绍了RabbitMQ的ack和nack机制。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档


前言

本文主要讨论RabbitMQ消费者的ack和nack机制,并且关注ack和nack使用上的问题记录,必要大家踩坑。

RabbitMQ的ack和nack机制

一、ACK机制

当生产者的发送消息到exchange,并路由到对应的队列后,MQ主动push消息到channel,由应用线程从channel中获取消息。
RabbitMQ的ack和nack机制

二、主动ACK

主动ACK是指在MQ主动push到channel中后,channel立马自动的给到MQ ack响应,然后MQ删除消息。
MQ使用的问题点:
1、当消费者宕机的情况下,会导致消息丢失,因为MQ已经删除了对应的消息。
2、只要队列中存在消息,MQ就会全部推送给消费者的channel。如果数据量过大,存在拖垮消费者的风险。

所以,一般使用MQ的时候选择使用手动ACK避免因消费者宕机等异常情况,导致消息丢失。

三、手动ACK

手动ACK即需要消费者主动的调用channel.ack()去通知MQ集群删除消息。
为了解决上面的第二个问题,手动ACK,一般需要搭配channel.basicQos()一起使用。Qos指的是预取量。即MQ每次发送给channel的未确认数量。
使用手动ACK也会出现如下的问题:
1、当消费逻辑发生异常后,消费者一直未主动调用channel.basicAck(),导致MQUnack数量骤升,导致MQ性能下降,甚至崩溃。
2、使用Qos,但是消费逻辑失败,未主动Ack,导致Mq unack的数量超过Qos的值。MQ将不再给消费者分配消息,阻塞整个队列,导致消息推积。

为了解决上面消费失败未主动ACK问题:
思路便是:
捕获消费处理的异常,消费成功调用channel.basicAck(). 消费失败时调用channel.basicNack()告诉MQ,消息消费失败了。

四、Nack机制

但是使用channel.basicNack又会引发另外的问题:
问题是当调用channel.basicNack后,消息会被重新存放的MQ队列的头部。下一步又消费这条会出异常的消息,又出错,塞回队列……
进入了死循环了,当然新的消息不会消费,导致堆积了。

为了解决消费失败后死循环的问题
1.创建死信队列,消费失败后通过调用channel.basicReject()进入死信队列。
2.消费失败后,存入存储中间件(Mysql , redis)等进行重试消费。

五、MQ unack的影响

接下来我们来分析下MQ中unack的数量过多的影响。
RabbitMq的设计就是允许消费者客户端很久不做ack,所以对于unack的消息,RabbitMQ并不会主动的去删除消息。并且MQ的的unack消息是存放在内存的,当队列中unack消息过多,会占用大量内存,导致MQ性能下架。除非consumer断连。这些unack的消息才会重新回到reday状态。

总结

为了解决上述使用RabbitMQ-ack的问题。
1、为了提供消息可靠性,应该使用RabbitMQ的手动Ack。
2、选择合适Qos值,一般建议100-300。太少可能存在队列推积,太多会占用MQ的内存。
3、当消费失败后,不能使用channel.basicNack() ,应该配合死信队列和存储中间件进行重试。
4、开启手动ACK后需要及时主动ack,避免因MQ unack数量骤升导致的MQ性能下降。文章来源地址https://www.toymoban.com/news/detail-509283.html

到了这里,关于RabbitMQ的ack和nack机制的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • SpringBoot-RabbitMQ06-持久化和ACK确认机制

    1.什么是消息确认ACK? 如果在处理消息的过程中,消费者的服务器在处理消息时出现异常,那么可能这条正在处理的消息刘没有完成消息消费,数据就会丢失,为了确保数据不会丢失RabbitMQ支持消息确认-ACK 2.ACK的消息确认机制 ACK机制是消费者从RabbitMQ收到消息并处理完成后,反

    2024年04月15日
    浏览(34)
  • I2C协议关于ack和nack的思考

    clock时钟是由master端产生的,而不管master还是slave都可以发送ack/ack。ack/nack由receiver产生。 当master是发送器,slave是接收器时,ack/nack由slave接收器产生。如,在地址传输周期内,和master进行写操作的周期内,ack/nack是由slave接收器产生。 当master是接收器,slave是发送器时,ack/

    2024年02月09日
    浏览(46)
  • RabbitMQ高级特性解析:消息投递的可靠性保证与消费者ACK机制探究

    学习RabbitMQ高级特性,涵盖消息的持久化、确认模式、退回模式以及消费者ACK机制等方面,助您构建高可靠性的消息队列系统。

    2024年01月16日
    浏览(64)
  • RabbitMQ初级篇:生产者与消费者关系、消息确认机制(ACK)、交换器与队列进行消息路由和存储

    在RabbitMQ中,生产者(Producer) 负责发送消息 ,通常是应用程序向RabbitMQ服务器发送具有特定路由键的消息;消费者(Consumer)则 负责处理接收到的这些消息 。在RabbitMQ中,生产者和消费者之间使用 交换器(Exchange)和队列(Queue)进行消息路由和存储 。生产者将消息发送到

    2024年02月01日
    浏览(41)
  • kafka ack确认机制

    Kafka使用ACK(Acknowledgment)确认机制来确保消息在生产者和消费者之间的可靠传递。这个机制确保消息在被认为已成功发送或处理之前不会被丢失。Kafka的ACK确认机制有三个级别: acks=0: 这是最快速的确认级别,也是最不可靠的。生产者发送消息后不会等待任何确认,直接将

    2024年03月16日
    浏览(39)
  • RabbitMq 手动ACK

    如果我们设置的是自动确认的话,那么就会有当接收到消息,去处理消息的时候生成异常,那么就会有消息丢失的情况。这种异常可能是网络波动,服务器宕机等情况都会发生。 并且如果没有ACK 的话会导致mq 中的unacked 的数量飙升,可能会撑爆内存 所以大部分项目中都会去

    2024年02月12日
    浏览(44)
  • kafka的 ack 应答机制

    目录 一 ack 应答机制  二 ISR 集合  kafka 为用户提供了三种应答级别: all,leader,0 acks :0                这一操作提供了一个最低的延迟,partition的leader接收到消息还没有写入磁盘就已经返回ack,当leader故障时有可能丢失数据;         生产者发送完消息后不会等

    2024年02月04日
    浏览(29)
  • python rabbitmq 手动ack

    Centos 安装 RabbitMQ rabbitmq-doc

    2024年02月13日
    浏览(32)
  • RabbitMQ手动ACK与死信队列

    为了保证消息从队列可靠的达到消费者,RabbitMQ 提供了消息确认机制(Message Acknowledgement)。 默认情况下RabbitMQ在消息发出后就立即将这条消息删除,而不管消费端是否接收到,是否处理完,导致消费端消息丢失时RabbitMQ自己又没有这条消息了。所以在实际项目中会使用手动Ack。

    2024年02月12日
    浏览(52)
  • 浅谈RabbitMQ消费端ACK和限流

    消费者 ACK 和 消费端限流 ack指  Acknowledge ,确认。 表示消费端收到消息后的确认方式。 有三种确认方式: • 自动确认:acknowledge=\\\" none \\\" • 手动确认:acknowledge=\\\" manual \\\" • 根据异常情况确认:acknowledge=\\\" auto \\\",(这种方式使用麻烦,不作讲解) 其中自动确认是指,当消息一

    2024年02月19日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包