过期的邮件传递顺序RabbitMQ [英] Expired Message Delivery Sequence RabbitMQ

问题描述

我们正在构建一种解决方案，其中将消息发布到超时队列中. TTL到期消息被推送到主队列以进行重新处理之后.

We are building a solution in which we are publishing message to a time-out queue. After TTL expiry messages are pushed to main queue for re-processing.

我们正在设置计数器值，以便尝试对x号进行消息发送.重新交付的时间.

We are setting up counter value so that messages will be tried for x no. of times for the redelivery.

解决方案工作正常.但是这种情况是，当头部位置最高的TTL消息没有过期时，其他过期时间较短的消息将不会重新发布(到主队列).

Solution is working fine. But the scenario is when the message on the head position is highest TTL is not expired, other messages of lower expiry will not be re-published (to main queue).

这种理解正确吗?如果是，那么解决方案是什么，以便仅在TTL之后重新处理每条消息.

Is this understanding correct ? If Yes what is the solution so that each message re-processed just after TTL.

欣赏答案/观点.

谢谢.

推荐答案

如果您使用按队列发送消息TTL，则消息将过期并从头到尾从队列中删除(按发布的顺序).

If you use per-queue message TTL, then message expires and get removed from queue from head to tail (in the same order they was published).

当您使用每条消息TTL时，仅当消息到达队列头时才将其从队列中删除，因此过期消息仍驻留在队列中间的情况是正常的.这样的消息将不会发送给使用者，并且将被置为死信(或丢弃)，但是由于严格的FIFO性质或RabbitMQ的队列(如上所述)会发生，当它们到达队列头并且在删除之前的延迟可能大于实际消息TTL .例如，如果有两条消息，第一条消息的TTL = 10sec，第二条消息的TTL = 1sec，则第二条消息也将在10秒内成为死信，而第二条消息将停留在第一条消息之后.

When you use per-message TTL, then messages removed from queue only when they reach queue head, so situation when expired messages still reside in the middle of queue is normal. Such messages will not be send to consumer, and will be deadlettered (or dropped), but due to strict FIFO nature or RabbitMQ's queues that will happen as written above, when they reach queue head and delay before removal may be greater than actual message TTL. For example, if there are two message, first with TTL=10sec and the second one with TTL=1sec, second message will be deadlettered also in 10sec while it stay after first one.

要处理具有不同TTL的消息，通常的解决方法是声明几个队列，每个队列用于具有相同TTL或几乎相同(例如，精度为10秒)的消息.实际精度可能会有所不同，尽管它具有非常特定的应用程序和某种经验值.

To deal with messages that has different TTL, common workaround is to declare few queues, each for messages with same TTL or almost same, say, with precision 10sec. Actual precision may vary while it very application-specific and somehow empirical value.

如果要选择单独的按TTL队列，请使用按队列TTL而不是按消息TTL，以简化消息工作流程并防止歧义化理解消息发生的情况.您之后的开发人员将对此表示感谢.

If you will pick separate per-TTL queues, use per-queue TTL rather than per-message TTL for ease of messages workflow and to prevent disambiguation of understanding what happens with messages. Developers after you will thank you for that.

要在TTL结束后重新处理消息，请使用死信交换，但要注意循环发送的消息问题:如果RabbitMQ代理检测到您的消息工作流已循环(从消息中删除消息后，消息将使用相同的路由密钥发布到同一交换中)，它将默默地丢弃消息.

To re-process messages after their TTL use Dead Letter Exchanges, but beware of cycled messages problem: if RabbitMQ broker detects that your messages workflow cycled (messages get published to same exchange with the same routing key after it was deadlettered from it), it will silently drop message.

这篇关于过期的邮件传递顺序RabbitMQ的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！