RabbitMQ手动ack模式下消费者长时间延迟返回ack是否合理？

RabbitMQ服务端与客户端的原生设计完全支持该类使用模式，核心逻辑及注意事项如下：

• 只要消费者显式配置了手动确认模式（即autoAck=false），RabbitMQ服务端默认不会对未收到ack的消息设置超时规则：只要消费者与服务端的TCP连接保持正常，服务端会一直持有该条消息，直到消费者返回ack/nack指令，或是消费者连接断开后，才会将消息重新投递到其他在线消费者。
• 该场景下需要额外注意两个配置项：
  • 3.8.15版本之后RabbitMQ新增了可选的delivery_acknowledgement_timeout配置，该配置默认处于关闭状态，不要主动开启即可避免服务端主动超时回收未确认的长耗时消息。
  • 需合理调整客户端与服务端的心跳超时参数，避免消息处理过程中消费者长时间无数据收发，被服务端判定为连接异常断开。默认心跳超时时间为60s，你可以根据业务最长消息处理时长调整阈值，也可以在消息处理逻辑外单独启动异步线程维持心跳交互，保证连接存活。
• 额外优化建议：长耗时消息消费场景建议搭配prefetch_count=1的预拉取配置，避免消费者一次性拉取多条消息后，后续消息长时间滞留在客户端无法被及时处理。

内容的提问来源于stack exchange，提问作者Incömplete