如何处理RabbitMQ Dynamic Shovel转发过程中卡住的消息

Dynamic Shovel本身没有内置投递失败直接路由死信的独立配置项，可通过以下组合配置实现需求：

方案一：源队列DLX配置+Shovel失败策略调整（最适配现有架构） #

• 先给Shovel正在消费的待转发队列配置死信规则，队列声明时添加以下参数：

  x-dead-letter-exchange: <你预设的DLX交换机名称>
  x-dead-letter-routing-key: <超限消息对应的死信路由键>
  

  绑定好DLX对应的死信队列，用于存储所有投递失败的超限消息。
• 修改Dynamic Shovel的配置，新增/调整以下参数：
  • 将requeue-on-nack设置为false：默认情况下Shovel投递失败后会把消息重新塞回源队列循环重试，关闭该配置后，投递失败返回nack的消息会直接触发源队列的死信规则，路由到预设的DLX
  • 可同步调整ack-mode为on-publish，确保投递结果返回后才处理消息确认逻辑
  • 按需调整reconnect-delay参数，避免频繁重连产生额外无效流量

注：requeue-on-nack参数在RabbitMQ 3.8及以上版本原生支持，低于该版本需升级RabbitMQ，或采用第二种方案。

方案二：前置消息过滤，从根源避免超限消息进入转发链路 #

如果不希望超限消息被Shovel消费，可在入队阶段就完成大小校验：

• 生产端改造：发送消息前先校验大小，超过1MB的消息直接写入专门的大容量消息处理队列，不进入Shovel消费的待转发队列
• 无生产端改造权限时，可给待转发队列绑定RabbitMQ策略，设置max-length-bytes=1048576，同时搭配DLX配置，超限消息入队时就会被直接路由到死信队列，不会被Shovel消费

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