azure - NServiceBus 和 Azure 长时间运行处理程序模式

Question

我们通过 NServiceBus 使用 Azure 服务总线，我在决定正确的架构来处理由于消息而导致的长时间运行的任务时遇到了问题。

作为良好实践，我们不想通过使其等待长时间运行的进程(从远程服务器下载大文件)来阻止消息处理程序返回，而实际上这样做会导致消息锁定与 Azure SB 一起迷失。该计划是通过生成一个单独的任务来响应，并允许消息处理程序立即返回。

但是，这意味着处理程序现在可立即用于下一条消息，这将导致生成另一个任务，依此类推，直到消息队列为空。我想要的是在我们处理(有限数量的)早期消息时停止接收消息的某种方法。 NServiceBus 和 Azure 服务总线是否有可接受的模式？

如果我直接针对 Azure SB 进行编程，以下是我会做的事情

{
     while(true)
     {
          var message = bus.Next();

          message.Complete();

          // Do long running stuff here 
     }
}

动词 Next 和 Complete 可能是错误的，但在 Azure 下发生的情况是 Next 会临时锁定消息，以便其他使用者无法再看到该消息。然后您可以决定是否确实要处理该消息，如果是，则调用 Complete。然后，该消息会从队列中完全删除，如果不这样做，将导致该消息在一段时间后重新出现在队列中，因为 Azure 会认为您崩溃了。尽管这段代码看起来很脏，但它可以实现我的目标(所以为什么不这样做呢？)，因为我的消费者只会在下次我有空时(在长时间运行的任务之后)消费。如有必要，其他消费者(其他实例)可以加入。

问题在于 NServiceBus 添加了一个抽象级别，因此现在可以通过处理程序类上的方法来处理消息。

void Handle(NewFileMessage message)
{
    // Do work here
}

问题在于，直到您完成工作并且 Handle 方法退出之后，Azure 才会调用 message.Complete()。这就是为什么你需要保持工作简短。然而，如果您退出，您也表示您已准备好处理另一条消息。这是我的第二十二条军规

Answer 1

在后台线程上下载是个好主意。您不想增加锁定持续时间，因为这是一种症状，而不是问题。您的下载很容易就会超过最大锁定持续时间(5 分钟)，然后您就会回到第一步。

您可以做的是下载编排传奇。 Saga 可以监控下载过程，当下载完成时，b/g 进程会向 saga 发出完成信号。如果下载从未完成，您可以设置一个超时(或多个超时)来指示该情况，并采取补偿操作或重试，无论什么适合您的业务案例。

有关 Sagas 的文档应该可以帮助您入门:http://docs.particular.net/nservicebus/sagas/