3

所以我有一个 azure 函数充当调用内部托管 API 的队列触发器。

关于如何处理由于有毒以外的问题而无法处理的消息，网上似乎没有明确的答案。

一个例子：

收到我的消息并且该函数尝试调用 API。消息有效负载是正确的，并且可以处理，但是无论出于何种原因，API/服务都已关闭（此时间可能超过 10 分钟）。目前发生的情况是消息传递计数达到其最大值（10），然后被推送到死信队列，这反过来又发生在每条消息之后。

我需要一种方法来不增加交付计数或在达到最大值时将其重置。或者，我可以在不增加传递计数的情况下放弃对消息的 peek 锁定，因为我想停止处理队列中的任何消息，直到 API/服务重新启动并运行。这样，我将确保所有可以处理的消息都不会因为服务之间的连接问题而陷入死信。

关于如何实现这一目标的任何想法？

4

1 回答 1

4

目前发生的情况是消息传递计数达到其最大值（10），然后被推送到死信队列，这反过来又发生在每条消息之后。

正如本文档所述关于Exceeding MaxDeliveryCount：

队列和订阅有一个 QueueDescription.MaxDeliveryCount/SubscriptionDescription.MaxDeliveryCount 设置；默认值为 10。每当消息在锁定 (ReceiveMode.PeekLock) 下传递，但已被明确放弃或锁定已过期时，消息的 BrokeredMessage.DeliveryCount 就会递增。当 DeliveryCount 超过 MaxDeliveryCount 时，消息被移动到指定“MaxDeliveryCountExceeded”原因代码的 DLQ。

此行为无法关闭，但 MaxDeliveryCount 可以设置为一个非常大的数字。

根据您的要求，我假设您可以按照以下方法来实现您的目的：

  • 用于在 ReceiveMode.PeekLock 下接收消息

    您可以在 Azure 门户上的服务总线队列的“设置 > 属性”下指定介于 1 和 2147483647 之间的最大传递计数。

  • 用于在 ReceiveMode.ReceiveAndDelete 下接收消息

当您的 API/服务关闭时，您可能会try-catch出现异常，然后您可以将消息重新发送到您的队列。

于 2017-06-01T03:29:38.967 回答