能否调整Dapr PubSub的重试策略以降低重试频率？

该场景完全可以对重试速率进行限流调控，以下是适配你方技术栈（AKS + .NET 5 + Dapr + Azure Service Bus）的可行方案：

Dapr官方的Azure Service Bus PubSub组件原生支持控制重试相关的时间参数，无需修改业务代码，直接更新AKS中部署的Dapr组件YAML即可生效：

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: azure-servicebus-pubsub
spec:
  type: pubsub.azure.servicebus
  version: v1
  metadata:
  - name: connectionString
    value: "你的Azure Service Bus连接字符串"
  # 单次消费的消息锁时长，需要大于你的业务逻辑单次处理的最大耗时，避免消息未处理完就被重新投递
  - name: lockDurationInSeconds
    value: "30"
  # 你方已经确定的最大重试次数，和后续弹性策略配置对齐即可
  - name: maxDeliveryCount
    value: "10"
  # 消息最大存活时间，超过该时间未被成功处理则自动进入死信队列
  - name: defaultMessageTimeToLiveInSeconds
    value: "3600"

配置更新后Dapr会自动热加载，无需重启业务Pod。

如果需要实现每次失败后重试间隔拉长的效果，可以通过Dapr的弹性策略CRD配置指数退避规则，适配你方对低重试频率的要求：

apiVersion: resiliency.dapr.io/v1alpha1
kind: Resiliency
metadata:
  name: pubsub-retry-policy
spec:
  policies:
    retries:
      pubsub-consume-exponential-retry:
        # 配置为指数退避模式，每次重试间隔翻倍
        policy: exponential
        # 初始重试间隔
        duration: 10s
        # 最大重试间隔，达到该值后不再继续拉长间隔
        maxDuration: 5m
        # 和组件配置的maxDeliveryCount对齐即可
        maxRetries: 10
  targets:
    components:
      # 填写你方实际使用的PubSub组件名称
      azure-servicebus-pubsub:
        inbound:
          retry: pubsub-consume-exponential-retry

该配置同样可以直接在AKS中部署生效，不需要修改业务代码，Dapr会自动在消费失败时按照配置的间隔执行重试。

如果有更复杂的自定义重试逻辑（比如针对不同异常类型设置不同的重试间隔），可以在.NET业务代码中捕获依赖不可用的异常后，通过Azure Service Bus的定时投递能力手动控制下一次重试的时间：

• 捕获异常后，调用Dapr .NET SDK的PublishEventAsync方法，通过PublishEventOptions指定ScheduledEnqueueTime参数，将消息重新投递到对应主题，设定为你需要的间隔时间后再出队
• 当前消费逻辑直接返回成功，避免触发Dapr的默认快速重试
• 注意需要在消息头中自行记录重试次数，避免无效消息无限循环投递

• Dapr弹性策略需要Dapr运行时版本在1.7及以上，AKS中安装的Dapr扩展默认已经开启该功能
• 所有配置的重试参数需要和Azure Service Bus队列/主题的原生参数对齐，避免两边策略冲突导致重试不符合预期
• 建议配置死信队列，所有超过最大重试次数的消息自动转入死信队列，后续人工排查处理

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