c# - 在 IHostBuilder 托管服务中推迟和重新接收推迟的消息

Question

如果 Azure 服务总线消息的处理依赖于其他资源，例如API或数据库服务，并且此资源不可用，不调用CompleteMessageAsync()不是一个选项，因为消息将立即再次接收，直到达到最大传递计数，然后放入 DLQ。如果 API 因维护而关闭，我们希望在重试之前稍等一下。

this question 的答案之一具有延迟和接收延迟消息的一般步骤。这比 Microsoft 的文档好一点，但不足以让我理解 API 的意图，以及如何在基本上整天位于 ServiceBusProcessor.StartProcessingAsync 中的托管服务中实现它。

这是我的服务的基本结构:

public class ServiceBusWatcher : IHostedService, IDisposable
{
    public Task StartAsync(CancellationToken stoppingToken)
    {
        ReceiveMessagesAsync();
        return Task.CompletedTask;
    }

    private async void ReceiveMessagesAsync()
    {
        ServiceBusClient client = new ServiceBusClient(connectionString);
        processor = client.CreateProcessor(queueName, new ServiceBusProcessorOptions());
        processor.ProcessMessageAsync += MessageHandler;
        await processor.StartProcessingAsync();
    }

    async Task MessageHandler(ProcessMessageEventArgs args)
    {
         // a dependency is not available that allows me to process a message. so:
         await args.DeferMessageAsync(args.Message);       

一旦消息被推迟，据我所知，处理器将不再获取它(或者会吗？)。相反，我必须使用 ReceiveDeferredMessageAsync() 来接收它，以及最初接收到的消息的序列号。

就我而言，等待几分钟或几小时再重试是有意义的。这可以通过使用计时器和显式调用 ReceiveDeferredMessageAsync() 的单独服务来完成。 ，而不是使用 ServiceBusProcessor。我还认为延迟的消息序列号必须保留在非 volatile 存储中，这样它们就不会丢失。

这听起来是一个可行的方法吗？我不喜欢必须记住它的序列号，以便稍后可以查看消息。它违背了使用消息队列首先带来的一切。

或者，我可以发布一 strip 有序列号的新“内部”消息，并使用ScheduledEnqueueTimeUtc，而不是推迟。属性以延迟接收。一旦我收到这条消息，我可以调用ReceiveDeferredMessageAsync()使用该序列号来获取原始消息。这表面上看起来很优雅，但如果依赖项的中断时间较长，消息可能会迅速增加。

另一个无需其他服务即可工作的想法:我可以完成并重新发布消息的有效负载并设置 ScheduledEnqueueTimeUtc到 future 的某个时间，如 the question I mentioned earlier 的另一个答案中所述。假设这可行(微软的文档没有提到这个属性的用途)，它看起来简单干净，我喜欢简单。

你是怎么解决这个问题的？是否有更好/首选的方法可以平衡低复杂性和高鲁棒性而不需要大量代码？

Answer 1

当您知道稍后要检索什么消息并且接收者将保存消息序列号以检索延迟的消息时，延迟消息就有效。如果接收方没有能力保存消息序列号，那么延迟消息是更好的选择。延迟消息意味着将原始消息数据复制到新安排的消息中并完成原始消息。这样，消费者既不必保留消息序列号，也不必启动特定消息的检索。