NServiceBus多队列实例如何仅为单个队列配置自定义Delay Retries

核心逻辑前提 #

NServiceBus的延迟重试策略本身不以物理队列作为配置绑定维度，而是以消息处理上下文关联的消息类型作为判断依据。无需为物理队列单独打配置标签，只要把需要特殊重试规则的消息集合与目标队列做路由绑定，再通过自定义重试策略做类型匹配，就能实现仅针对目标队列生效的定制规则，完全不会影响其他队列的默认配置，且逻辑对RabbitMq、Azure Service Bus两类传输完全兼容。

具体实现步骤 #

• 第一步：完成队列与消息的路由隔离
  确保承载第三方服务调用逻辑的所有消息类型，其路由配置全部指向目标专属队列；同时保证其他普通业务消息不会被路由到这个队列，从路由层面实现消息集合的边界隔离，避免后续自定义规则被其他消息误触发。
• 第二步：编写分层的可恢复性配置
  首先在Endpoint初始化阶段，先为所有非目标队列配置通用的默认延迟重试规则，作为全局兜底配置；再通过自定义重试策略，单独为目标队列关联的消息类型挂载专属的重试规则，代码实现参考如下：

  // 初始化承载多队列处理逻辑的Endpoint实例
  var endpointConfig = new EndpointConfiguration("你的处理实例标识");
  
  // 配置默认的全局延迟重试规则，对所有普通队列生效
  endpointConfig.Recoverability()
      .Delayed(defaultSettings =>
      {
          defaultSettings.NumberOfRetries(3);
          defaultSettings.TimeIncrease(TimeSpan.FromSeconds(10));
      });
  
  // 注册全局可恢复性自定义策略，实现按消息类型区分规则
  endpointConfig.Recoverability()
      .AddCustomPolicy((recoverabilityConfig, processingContext) =>
      {
          // 匹配目标队列关联的第三方调用消息类型，应用专属重试规则
          if (processingContext.Message.MessageType == typeof(ThirdPartyServiceIntegrationRequest))
          {
              var currentRetryAttempt = processingContext.GetRetryAttempt();
              // 达到最大10次重试阈值后，转移到错误队列
              if (currentRetryAttempt >= 10)
              {
                  return RecoverabilityAction.MoveToError(processingContext.Exception);
              }
              // 按照预先定义的特定时间间隔序列，计算每次重试的延迟值
              var customDelay = GetDefinedRetryDelayPattern(currentRetryAttempt);
              return RecoverabilityAction.DelayedRetry(customDelay, processingContext.Exception);
          }
  
          // 非目标类型的消息，走之前配置的全局默认规则，不做任何拦截
          return DefaultRecoverabilityPolicy.Invoke(recoverabilityConfig, processingContext);
      });
  

• 第三步：跨传输的兼容性适配验证
  上述配置逻辑完全不绑定具体传输组件，测试、生产环境的适配无需改动核心重试逻辑：
  • 测试环境RabbitMq：只要确认RabbitMq延迟插件正常加载，自定义策略计算出的延迟值会自动被映射到对应的延迟交换机路由逻辑，无需额外修改重试代码。
  • 生产环境Azure Service Bus：自定义策略计算的延迟值会自动适配ASB内置的延迟投递、自动重试的原生能力，不需要硬编码ASB专属的队列操作逻辑。

常见避坑点 #

• 不要通过物理队列名称做规则匹配：在多队列处理实例的上下文里，处理阶段获取的队列标识通常是Endpoint的统一输入队列名，靠队列名判断规则很容易出现串配置的问题；正确的匹配依据是消息类型本身——因为目标队列已经通过路由做了消息隔离，消息类型判断比队列名判断稳定得多。
• 避免目标队列混入其他消息：如果有非目标业务消息被错误路由到专属队列，这些消息也会触发自定义的10次重试规则，出现预期外的行为。
• 自定义策略不要阻断默认逻辑：所有非目标类型的消息处理必须回传给默认重试策略，否则会直接冲掉之前配置的全局通用规则，影响其他队列的正常运行。

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