azureservicebus - Azure Service Bus SubscriptionClient 中的哪些异常会导致重试？

Question

我正在努力解决消息在死信队列中过快结束的问题。我已经指定了这样的 ExponentialRetry 策略:

        private readonly RetryExponential _retryPolicy = new RetryExponential(
            TimeSpan.FromSeconds(1),
            TimeSpan.FromMinutes(20),
            10);

当 SQL Server 暂时关闭时(“因为它的副本角色是 RESOLVING，不允许连接。稍后再试该操作。”)然后消息最终进入死信队列 无需重试。

我该怎么做才能重试？

我查看了 the source code for the SDK ，似乎只有 transient ServiceBusException 会重试，但我觉得这很奇怪。

更新:

在与我的同事讨论并在 Application Insights 中进一步查看之后，我可以看到它实际上重试了 10 次，但都在 2 秒内。这是在订阅本身上设置的最大传送计数 - 而不是在客户端上。此交付不受我想要和需要的任何指数退避的影响。

Answer 1

I looked in the source code for the SDK, and it seems that only transient ServiceBusException give retries, but I find that quite odd.

这是正确的并且符合设计。当错误是暂时性错误(连接问题、限制等)时，客户端将使用 RetryPolicy 重试。否则，重试无济于事，因此重试相同的操作也无济于事。

针对您的具体情况 - 执行您的代码并处理消息。客户和经纪人之间没有问题。这就是政策没有生效的原因。此外，您确认这是一个应用程序问题，因为消息已被您的进程重试并最终进入死信队列。

I am struggling with messages ending up in dead letter queue too quickly.

您需要的是应用程序重试和退避，以确保消息不会立即多次重试，从而导致消息成为死信。这部分可能有点棘手，具体取决于您的 SQL 服务器停机的时间。有几个选项:

1. 将消息安排在以后，让 SQL Server 恢复。此选项将需要安排一条新消息。
2. 推迟消息并稍后处理。这意味着您需要保留延迟消息 SequenceNumber 的记录。实现此选项的一种方法是使用原始消息的序列号安排新消息。
3. 在服务总线之上使用抽象，提供高级概念/功能来执行重试，例如MassTransit或 NServiceBus ( Recoverability )。