本文介绍: TTL+死信队列实现逻辑,创建一个普通交换机跟队列,给队列设置TTL超时时间,但是不给这个队列绑定消费者,给这个普通队列绑定死信交换机,等到消息超时就会发送到死信交换机,给死信交换机配一个消费者来消费。为了更方便、更灵活地实现延迟队列功能,可以使用RabbitMQ提供的插件rabbitmq_delayed_message_exchange,这个插件为RabbitMQ提供了原生的延迟队列支持,允许在不使用死信队列的情况下直接实现延迟消息的发送和消费。

目录

死信队列

何时会产生死信

死信队列的配置方式

参数x-dead-letter-routing-key

如何确定一个消息是不是死信

延迟队列

懒队列

声明懒队列的两种方式

参数声明

 策略指定


死信队列

       死信队列是RabbitMQ中非常重要的一个特性。简单理解,他是RabbitMQ对于未能正常消费的消息进行的一种补救机制。死信队列也是一个普通的队列,同样可以在队列上声明消费者,继续对消息进行消费处理。

​ 对于死信队列,在RabbitMQ中主要涉及到几个参数:

       x-dead-letter-exchange指定一个交换机作为死信交换机,然后x-dead-letter-routing-key指定交换机的RoutingKey。而接下来,死信交换机就可以像普通交换机一样,通过RoutingKey将消息转发到对应的死信队列中。

何时会产生死信

以下三种情况,RabbitMQ会将一个正常消息转成死信

1. 消息被消费者确认拒绝。消费者把requeue参数设置为true(false),并且在消费后,向RabbitMQ返回拒绝。channel.basicReject或者channel.basicNack。

2. 消息达到预设的TTL时限还一直没有被消费。TTL即最长存活时间 Time-To-Live 。消息在队列中保存时间超过这个TTL,即会被认为死亡。如果配置了死信队列,死亡的消息会进入该队列。

设置TTL有两种方式,一是通过配置策略指定,另一种是给队列单独声明TTL。

策略配置方式: Web管理平台配置 或者 使用指令配置 30000为毫秒单位

rabbitmqctl set_policy TTL ".*" '{"message-ttl":30000}' --apply-to queues

声明队列时指定:同样可以在Web管理平台配置,也可以在代码中配置

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-message-ttl", 60000);
channel.queueDeclare("myqueue", false, false, false, args);

3. 消息由于队列已经达到最长长度限制而被丢掉。


死信队列的配置方式

       RabbitMQ中有两种方式可以声明死信队列,一种是针对某个单独队列指定对应的死信队列。另一种就是以策略的方式进行批量死信队列的配置。

针对多个队列,可以使用策略方式,配置统一的死信队列:

rabbitmqctl set_policy DLX ".*" '{"dead-letter-exchange":"my-dlx"}' --apply-to queues

针对队列单独指定死信队列的方式主要是之前提到的三个属性:

channel.exchangeDeclare("deadexchange", "direct");
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-dead-letter-exchange", "deadexchange");
channel.queueDeclare("myqueue", false, false, false, args);

 这些参数,也可以在RabbitMQ的管理页面进行配置。例如配置策略时:

       在对队列进行配置时,只有Classic经典队列和Quorum仲裁队列才能配置死信队列,而目前Stream流式队列,并不支持配置死信队列。


参数x-dead-letter-routing-key

       当消息被投递到死信队列时,它会携带原始消息的routing key,除非配置了 x-dead-letter-routing-key 参数,此时会将routing key替换为指定的值。需要注意的是,这个过程是由 RabbitMQ 管理的,而不经过消息发送者的确认,因此在死信消息转移的过程中,无法由发送者确保消息的安全性。

如何确定一个消息是不是死信

       消息被作为死信转移到死信队列后,会在Header当中增加一些消息。会加上第一次成为死信的三个属性,并且这三个属性在以后的传递过程中都不会更改。

x-first-death-reason
x-first-death-queue
x-first-death-exchange

延迟队列

       RabbitMQ中,是不存在延迟队列的功能的,而通常如果要用到延迟队列,就会采用TTL+死信队列的方式来处理。RabbitMQ提供了一个rabbitmq_delayed_message_exchange插件,可以实现延迟队列的功能,但是并没有集成到官方的发布包当中,需要单独去下载。

       TTL+死信队列实现逻辑,创建一个普通交换机跟队列,给队列设置TTL超时时间,但是不给这个队列绑定消费者,给这个普通队列绑定死信交换机,等到消息超时就会发送到死信交换机,给死信交换机配一个消费者来消费。这种方式可以实现延迟队列的功能。但在一些情况下可能会有一些局限性,比如无法实现非常精确的延迟。

        为了更方便、更灵活地实现延迟队列功能,可以使用RabbitMQ提供的插件rabbitmq_delayed_message_exchange,这个插件为RabbitMQ提供了原生的延迟队列支持,允许在不使用死信队列的情况下直接实现延迟消息的发送和消费。


懒队列

       RabbitMQ从3.6.0版本开始,就引入了懒队列(Lazy Queue)的概念。懒队列会尽可能早的将消息内容保存到硬盘当中,并且只有在用户请求到时,才临时从硬盘加载到RAM内存当中。懒队列的设计目标是为了支持非常长的队列(数百万级别)。队列可能会因为一些原因变得非常长也就是数据堆积。比如消费者服务宕机了、有一个突然的消息高峰,生产者生产消息超过消费者、消费者消费太慢了,都有可能造成数据堆积。

       默认情况下,RabbitMQ接收到消息时,会保存到内存以便使用,同时把消息写到硬盘。但是,消息写入硬盘的过程中,是会阻塞队列的。RabbitMQ虽然针对写入硬盘速度做了很多算法优化,但是在长队列中,依然表现不是很理想,所以就有了懒队列的出现。​ 懒队列会尝试尽可能早的把消息写到硬盘中。这意味着在正常操作的大多数情况下,RAM(内存)中要保存的消息要少得多(数据都在硬盘中)。

声明懒队列的两种方式

参数声明

在代码中可以通过x-queue-mode参数指定 

  Map<String, Object> args = new HashMap<String, Object>();
  args.put("x-queue-mode", "lazy");
  channel.queueDeclare("myqueue", false, false, false, args);
 策略指定
rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"default"}' --apply-to queues

       当一个队列被声明为懒队列,那即使队列被设定为不持久化,消息依然会写入到硬盘中。如果是在集群模式中使用,会给集群资源带来很大的负担。

       懒队列适合消息量大且长期有堆积的队列,可以减少内存使用,加快消费速度。但是这是以大量消耗集群的网络及磁盘IO为代价的

原文地址:https://blog.csdn.net/m0_61853556/article/details/135924072

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

如若转载,请注明出处:http://www.7code.cn/show_64515.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注