AWS Amazon-MQ托管RabbitMQ的Delivery Acknowledgement Timeout调整问题

关于是否可以调高AUTO模式下Delivery Acknowledgement Timeout的解答 #

你推测的30分钟超时是RabbitMQ 3.8及以上版本默认的consumer_timeout参数控制的，默认值为1800000毫秒（30分钟），该参数对所有需要确认的消费者生效，并非AUTO模式独有。
AWS Amazon MQ托管RabbitMQ支持修改该参数，你可以在Amazon MQ控制台对应Broker的配置管理页面，修改consumer_timeout的数值为你需要的毫秒值（最高支持设置为86400000毫秒即24小时），修改后重启Broker即可生效。

注意：该参数为全局生效配置，调大后如果出现消费者异常宕机未发送确认的情况，消息会被占用更长时间无法释放，可能加剧队列堆积问题，不建议设置过大。

其他可行解决方案 #

• 切换为手动确认模式（AcknowledgeMode.MANUAL）
  替换默认的AUTO自动确认模式，改为业务逻辑完全处理完成后，主动调用basic.ack方法发送确认信号，消息只有收到确认后才会被RabbitMQ删除。该模式下不会因为任务处理时长超过阈值被主动踢出消费者列表，你只需要做好异常分支的处理，执行失败时调用basic.nack标记消息状态即可，避免消息无限滞留。
• 长耗时任务拆分+状态标记
  生产环境更推荐该方案：将耗时超过30分钟的任务拆分为多个短周期执行的子步骤，每个子步骤处理完成后立即确认当前消息，同时下发下一步骤的任务消息；也可以在消费到消息后，先将任务状态标记为「处理中」存入持久化存储，直接确认消息，再异步执行长耗时任务，执行完成后更新任务状态，执行失败时触发补发逻辑，从根本上避免长耗时任务占用未确认消息的问题。
• 配置死信队列做兜底
  给业务队列配置死信队列和最大重试次数，消息重复消费重试超过阈值后直接进入死信队列，避免循环重复执行业务逻辑，后续只需单独处理死信队列中的异常消息即可。

内容的提问来源于stack exchange，提问作者Swagat