我了解带有 ack 的 RabbitMQ，默认情况下，如果检测到消费者/工作者已经死亡，它将重新排队消息。
consumer/worker 还活着但进程停滞太久没有 ack 的情况呢？
我想设置一个明确的时间，表示如果一条消息已发送给消费者，但该消费者在没有确认的情况下持有该消息的时间过长，那么该消息将被重新排队。
我知道这可能会导致消息被重复处理，但有时其后果并不像延迟消息传递那么糟糕。 如果某些东西被吞下，任务终止，并且消息永远不会被确认并且永远不会重新排队，那么错误的异常处理也会发生这种情况。
【问题讨论】：
RabbitMQ 消费者的超时可以在消费者端显式设置。我认为这很清楚，但只是提一下 - 在这种情况下不能有任何自动 ACK。解决方案是消费者是多线程的，一个线程进行消息处理并仅在处理完消息后才确认消息，而另一个线程是超时线程，它将：
instructing the broker to either discard them or requeue them)，似乎应该设置一些配置来指示代理应该如何处理 NACKed 消息
现在所有这些都意味着至少有一部分过程没有被卡住。如果整个过程都卡住了，也许经纪人对消费者的心跳停止了，这就是经纪人知道消费者死亡的方式（老实说我没有测试这种情况，所以我假设），但如果这不是在这种情况下（或者只是为了更加安全），您可以添加某种看门狗进程，该进程将 ping 消费者并在没有回复时将其杀死，这再次导致消息未被确认并被重新排队。
【讨论】：