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