Spring AMQP是否基于JVM重新排队消息计数？

Question

我翻阅了rabbitmq文档，似乎rabbitmq不处理消息重新传递计数。如果我要手动确认/NACK消息，我需要将重试计数保存在内存中（例如，使用correlationId作为映射中的唯一键），或者在消息中设置我自己的头并重新发送它（从而将其放在队列的末尾）

然而，这是一个Spring处理的情况。具体来说，我指的是RetryInterceptorBuilder.stateful（）。maxAttemts（x）。不过，这个计数是特定于JVM的，还是以某种方式操纵消息？

例如，我有一个Web应用程序部署到2台服务器，maxAttemcript设置为5。是否有可能总的重新交付计数在5-9之间，这取决于它在2台服务器之间重新交付和重新处理的顺序？

Answer 1

Rabbit/AMQP不允许在基于拒绝的重新执行时修改消息。

状态（基于MessageId）是在一个RetryContextCache中维护的；默认值是一个MapRetryContextCache。这并不真正适合于一个集群，因为，正如你所说，尝试最多可能是（（（maxAttemts-1）*n 1）；另外，它会导致内存泄漏（某些服务器上的状态）。您可以在RetryTemboard（RetryAction中配置一个SoftReancceMapRetryContextCache，以避免内存泄漏，但这只能解决内存泄漏。

您需要使用自定义的RetryContextCache与一些持久共享存储（例如redis）。

我通常建议在这种情况下使用无状态恢复——重试完全在容器中完成，根本不涉及兔子（直到重试用尽，在这种情况下，消息将被丢弃或发送到DLX/DLQ，这取决于代理配置）。

如果您不关心消息顺序（我假设您没有考虑到存在竞争的消费者），一种有趣的技术是拒绝消息，将其发送到具有过期设置的DLQ，当DLQ消息过期时，将其路由回原始队列的尾部（而不是头部）。在这种情况下，可以检查x-death标头以确定其重试次数。

这个回答和这个有更多的细节。