代码编织梦想

一、概述

来自队列的消息可以是“死信”;即,在发生以下任何事件时重新发布到交易所:

  • 使用者使用basic.ject或basic.nack对消息进行否定确认,重新排队参数设置为false。

  • 由于每条消息的TTL,消息过期;

  • 消息已被丢弃,因为其队列超过了长度限制

请注意,队列的过期不会使其中的消息成为死信。

死信交换(DLX)是正常的交换。它们可以是任何常见的类型,并按常规进行声明。

对于任何给定的队列,DLX可以由客户端使用队列的参数来定义,也可以在服务器中使用策略来定义。在策略和参数都指定DLX的情况下,参数中指定的DLX将替代策略中指定的。

建议使用策略进行配置,因为它允许不涉及应用程序重新部署的DLX重新配置。

二、使用策略进行配置

要使用策略指定 DLX,请添加密钥“死信交换” 到策略定义。例如:

Rabbitmqctl

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

rabbitmqctl (Windows)

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

上述策略将 DLX“my-dlx”应用于所有队列。这只是一个例子,在实践中 不同的队列集可能会使用不同的死信设置(或根本不使用)

同样,可以通过添加 策略的密钥“死信路由密钥”。

三、使用可选队列参数进行配置

要设置队列的死信交换,请在声明队列时指定可选的x-dead-letter-exchange参数。该值必须是同一虚拟主机中的交换机名称:

channel.exchangeDeclare("some.exchange.name", "direct");

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

上面的代码声明了一个名为some.exchange.name的新交换,并将此新交换设置为新建队列的死信交换。请注意,在声明队列时不必声明交换,但在消息需要使用死信时,它应该已经存在;如果它丢失了,那么消息将被静默地丢弃。

您还可以指定一个路由密钥,以便在死字消息时使用。如果未设置此项,则将使用消息自己的路由密钥。

args.put("x-dead-letter-routing-key", "some-routing-key");

指定死信交换后,除了对声明的队列具有通常的配置权限外,用户还需要对该队列具有读取权限,对死信交换具有写入权限。在队列声明时验证权限。

四、路由死信消息

死信消息被路由到其以下任一死信队列:

  • 使用为他们所在的队列指定的路由密钥;或者如果没有设置,

  • 使用与最初相同的路由密钥 发布者

例如,如果您将一条消息发布到具有路由关键字foo的交换机,并且该消息是死信的,则它将被发布到其具有路由关键字foo的死信交换机。如果消息最初到达的队列已声明为x-dead-letter-routing-key设置为bar,则消息将发布到具有路由密钥bar的死信交换机。

请注意,如果未为 队列,其上的消息是死信的,具有所有原始路由密钥。这包括路由密钥 由 CC 和密件抄送标头添加 (有关这两个标头的详细信息,请参阅发件人选择的分发)。

有可能形成消息死信的循环。为 实例,当队列死信时,可能会发生这种情况 发送到默认交换的消息,而不指定 死信路由密钥。此类循环中的消息(即 两次到达同一队列的邮件)将是 如果整个周期中没有拒绝,则丢弃。

五、安全

默认情况下,死信消息会在内部未启用发布者确认的情况下重新发布。因此,在集群中使用 DLX RabbitMQ 环境不保证安全。邮件将从 发布到 DLX 目标队列后立即启动原始队列。这确保了 没有可能耗尽代理的过度消息积累的可能性 资源,但如果目标队列不可用于接受消息,则消息可能会丢失。

由于 RabbitMQ 3.10 仲裁队列支持至少一次死信,其中消息在内部打开发布者确认的情况下重新发布。

六、对消息的死信影响

消息的死信会修改其标头:

  • 交易所名称将替换为最新的死信交易所名称,

  • 路由密钥可以替换为执行死信的队列中指定的密钥,

  • 如果发生上述情况,CC 标头也将被删除,并且

  • 密件抄送标头将根据发件人选择的分发删除

死信进程将数组添加到 每条死信消息都命名为X-Death。 此数组包含每个死信事件的条目, 由一对 {队列, 原因} 标识。 每个这样的条目都是一个包含 的几个字段:

  • 队列:消息在变为死信之前所在的队列的名称

  • 原因:死字的原因,见下文

  • time:消息作为 64 位 AMQP 0-9-1 时间戳的死信日期和时间

  • Exchange - 消息发布到的 Exchange (请注意,这将是一个死信 如果消息多次为死信,则交换)

  • 路由密钥:发布消息时使用的路由密钥(包括 CC 密钥,但不包括密件抄送密钥)

  • 计数:由于此原因,此消息在此队列中被死信的次数

  • 原始过期(如果消息由于每条消息的 TTL 而成为死信): 消息的原始过期属性。过期属性将从 关于死信的消息,以防止它在路由到的任何队列中再次过期。

新条目将附加到 x-death 数组的开头。如果 x-death 已经包含带有 相同的队列和死字原因,其计数字段将是 递增,它将被移动到数组的开头。

原因是描述为什么 消息是死信的,并且是以下之一:

  • 已拒绝:邮件被拒绝,重新排队参数设置为 false

  • 已过期:消息 TTL 已过期

  • maxlen:已超出允许的最大队列长度

  • delivery_limit:消息返回的次数超过了限制(由仲裁队列的策略参数传递限制设置)。

为第一个死信事件添加了三个顶级标题。他们是

  • X-第一死亡原因

  • X-第一死亡队列

  • X-第一次死亡交换

它们与原始死信事件的原因、队列和交换字段具有相同的值。一旦添加,这些标头就永远不会被修改。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/leesinbad/article/details/129653956