使用放弃的Service Bus消息重新触发Azure功能

Question

我有一个Service Bus主题，它有一个从Azure功能推送到它的400,000条消息。我有第二个Azure功能，它接收消息作为触发器。当第二个函数运行时，它成功处理了98％的消息。它给我留下了大约8,000条失败的消息。无论是来自异常还是来自我的代码，该消息都被放弃了。我现在收到了关于该主题的订阅者的8,000条消息，我无法让函数重新尝试处理。

订阅者最初设置为仅允许1次传递消息。我这样做是因为我看到同样的消息在调试时被多次处理。我不确定这是否是本地调试Visual Studio的副作用，或者是否会多次将消息发送到Function。我认为这是导致这些消息在被放弃之后没有重新运行的原因（如果支持甚至支持？）。

我已将订阅者传递次数更改为5，希望它会将消息重新传递给函数。它没有。现在我需要做些什么才能让剩余的8,000条消息再次触发第二个功能？

最糟糕的情况是，我可以删除订阅，重新创建订阅并再次运行第一个功能，这应该只发布与原始丢失的8,000条消息相关的数据（我有逻辑处理缺少的数据）功能）。这将导致第二个功能重新启动。我想知道如何处理它，虽然订阅时有像这样的孤立消息，因为当我升级到生产时我会体验到这一点。我希望这是自动化的，而不是第二次手动清理和重新运行过程。

以下显示主题中没有任何消息，但它们仍然存在于订阅中。

我在Full Framework上用C＃Functions 1.0编写了函数。

Answer 1

如果达到MaxDeliveryCount，则消息将被发送到deadletter队列 您可以将订阅视为子队列，以便仍然可以访问这些消息。

查看有关如何访问deadletter队列的帖子：

• How do you access the dead letter sub-queue on an Azure subscription?

首先，您的方案是增加MaxDeliveryCount。

然后，您可以创建一个函数，每当邮件到达deadletter queue / subscription时都会触发该函数：

 [FunctionName("my-subscription-failure")]
 public static async Task RunFailure(
        [ServiceBusTrigger("%MytopicName%", "%MySubscription%/$DeadLetterQueue", Connection = "MyconnectionString")] BrokeredMessage message,
        [ServiceBus( "%MytopicName%", AccessRights.Send, Connection = "MyconnectionString")] ICollector<BrokeredMessage> queueBinding,
        TraceWriter log, ExecutionContext context)
{
    // fist check if the message can be resent (it could be a message that can't be replay)
    ...

    // If ok, resent the message
    queueBinding.Add(message);
}