RabbitMQ/MassTransit中unacked消息待重试时如何处理ready消息

当前配置的UseMessageRetry是进程内内存重试机制：重试等待阶段消息会持续保持unacked状态被消费者进程持有，同时占用RabbitMQ预取（Prefetch）配额和消费者并发处理槽位。当所有可用槽位被等待15分钟长间隔重试的消息占满后，RabbitMQ Broker不会再向该消费者投递新的ready消息，即出现观测到的阻塞现象。
此外内存重试不适配长间隔场景：重试等待期间如果消费者发生重启、崩溃，内存中存储的重试进度会完全丢失，对应消息会重新回到队列头部重复之前的处理流程，可靠性无保障。

按以下方式调整配置即可避免重试阻塞新消息：

• 替换长间隔内存重试为Broker端延迟重投递
  15分钟这类长间隔重试不要使用内存式UseMessageRetry，改用MassTransit内置的延迟重投递能力UseDelayedRedelivery。
  前置准备：为RabbitMQ 3.8.7安装官方rabbitmq_delayed_message_exchange插件，MassTransit RabbitMQ传输层原生适配该插件实现延迟调度，无需额外定制开发。
  配置示例：

  endpointConfigurator.UseDelayedRedelivery(r => r.Intervals(
      TimeSpan.FromSeconds(10),
      TimeSpan.FromMinutes(15)));
  

  该配置的运行逻辑：消息处理失败后，消费者会直接确认（ack）原消息，将需要延迟重试的消息投递到RabbitMQ的延迟交换器存储；等待重试期间消息完全在Broker侧，不占用消费者并发槽位和unacked配额，新到达的ready消息可以被正常调度处理；到达预设重试时间后，Broker才会将消息重新投递给消费者执行重试逻辑。两次重试全部失败后，消息仍会按预期移入error队列，和原有错误处理逻辑一致。
• （不推荐）调整预取配额适配短重试
  如果要保留10秒这类极短间隔的内存重试，可以适当调高PrefetchCount参数，预留足够配额给新消息投递。但该方案无法解决长间隔重试下的消费者重启丢重试进度问题，仅适合秒级以内的短重试场景。

MassTransit 7.0.4版本中，未显式调用UseConcurrencyLimit配置时，默认并发限制为 运行环境逻辑CPU核心数 × 2。
该默认值同时会作为RabbitMQ传输层的默认PrefetchCount值，和测试观测到的现象完全匹配：测试环境为4核CPU时，默认并发与预取配额为8，刚好被8条等待重试的unacked消息占满，剩余2条ready消息无法获得投递配额。

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