【发布时间】：2014-10-03 06:23:36
【问题描述】：
有没有什么方法可以在不手动重新排队作业的情况下计算作业重新排队的次数（通过 Reject 或 Nak）？ 我需要重试作业 'n' 次，然后在 'n' 次后放弃它。
ps：目前我手动重新排队作业（删除旧作业，如果 Counter 不存在或值小于“n”，则创建具有确切内容和额外 Counter 标头的新作业）
【问题讨论】：
【发布时间】：2014-10-03 06:23:36
【问题描述】：
有redelivered消息属性在消息重新传递一次或多次时设置为true。
如果您想跟踪重新传递计数或剩余的重新传递数量（也就是 IP 堆栈中的跳数限制或 ttl），您必须将该值存储在消息正文或标头中（字面意思是 - 使用消息，修改它，然后将它修改后发布回经纪人）。
也有类似的问题有答案可以帮到你：How do I set a number of retry attempts in RabbitMQ?
【讨论】：
-
值得注意的是，RabbitMQ 端的重试计数没有实现，也不是那么容易做到，因为它需要更改相当多的用于存储消息的数据结构。我们可能会在未来实施，但实际上没有 ETA
-
没错，我发布了在应用程序端计数的重试作为一种解决方法。确实，消费、修改然后再次发布消息有很多缺点，比如稳定性和性能潜在问题，但作为一种解决方法，它是有效的。如果你曾经想过实现它会很棒（至少看起来像）有一个单独的插件来利用标题修改和尊重，比如递增
x-redelivered-count或递减x-redeliveries-left直到它达到零，然后应用DLX或 AE 机制或干脆丢弃消息。
如果消息实际上是死信，您可以检查x-death消息头的内容。
例如，当您 reject/nack 与 requeue = false 并且队列具有关联的死信交换时，就会出现这种情况。
在这种情况下，此标头的内容是一个数组。每个元素描述一次失败的传递尝试，包含尝试传递的时间、路由信息等信息。
这适用于 RabbitMQ - 我不知道它是否适用于一般的 AMQP。
编辑
自从我最初编写此答案以来，x-death 标头结构已更改。
标题改变格式通常是一件非常糟糕的事情，但是 在这种特殊情况下，原因是如果消息连续死信，消息大小将无限增长。
因此，我删除了用于获取消息死亡人数的代码。
仍然可以从新的标题格式中获取死亡人数。
【讨论】：
-
x-death仅在消息为死信时添加。 -
@MartinSchröder - 好点 - 我从一个示例中获取代码，我们使用死信交换来处理稍后的重新交付。我更新了答案以反映这一点