我正在通过AWS Amazon-MQ使用托管RabbitMQ集群。如果使用者快速完成工作，则一切都正常。但是，根据少数情况，很少有使用者花费超过30分钟来完成处理。在这种情况下，RabbitMQ删除消费者并使相同的消息在队列中再次可见。由于这一点，另一个消费者拿起它并开始处理。这是在循环中发生的。因此，相同的事务再次执行，我也失去了消费者。我没有使用任何AcknowledgeMode，所以我相信默认情况下它是自动的，并且有30分钟的限制。是否有任何方法可以增加自动模式的交付确认超时？或者，如果有人对此有任何其他解决方案，请告诉我。
2条答案
按热度按时间vsmadaxz1#
来自AWS支持的回复：
现在可以配置使用者超时，但只能由服务团队完成。无论版本如何，更改都将是永久性的。
所以你可以更新RabbitMQ到最新版本，而不需要坚持使用3.8.11。提供你的经纪人详细信息和所需的超时时间，他们应该能够为你做这件事。
r1zhe5dt2#
这是来自AWS支持的响应。
根据我的理解，我看到您的工作负载当前受到v3.8.15中引入的consumer_timeout参数的影响。由于这个原因，我们已经有了一些联系，不幸的是，服务团队已经确认，虽然他们可以手动编辑rabbitmq.conf，此设置将在下次重新启动或故障切换时被覆盖，因此不是推荐的解决方案。这也意味着代理上应用了手动更改的所有安全修补程序都必须暂停。当前，该服务不支持从该配置文件中为RabbitMQ进行自定义用户配置。但已确认他们希望在未来解决此问题，但无法确定何时可用。
从RabbitMQ github来看，这似乎是为v3.8.15（https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.8.15）中的仲裁队列添加的，但似乎适用于所有使用者（https://github.com/rabbitmq/rabbitmq-server/pull/2990）。
不幸的是，RabbitMQ本身不支持降级（https://www.rabbitmq.com/upgrade.html）因此，服务团队建议的变通方法和最安全的操作是在旧版本上创建一个新代理（3.8.11）并将自动次要版本升级设置为false，这样它就不会被升级。然后从现有RabbitMQ示例中导出配置，并将其导入到新示例中，然后继续使用此示例。