Azure 服务总线队列消息处理

Posted 2023-03-10

【中文标题】Azure 服务总线队列消息处理

【英文标题】：Azure Service Bus queue message handling

【发布时间】：2017-11-01 07:42:11

【问题描述】：

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

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

一个例子：

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

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

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

【问题讨论】：

您解决了这个问题吗，需要进一步的帮助吗？

我很抱歉没有回复。我认为在服务/api 停机的情况下，我们将通过休眠线程和增加交付计数来延迟触发器重试。这样，如果它出现故障，它不会立即达到最大交付计数并陷入死信。感谢您的帮助

【参考方案1】：

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

正如document 所说的超过 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 异常，然后您可以将消息重新发送到您的队列。

【讨论】：

我考虑过捕获异常并将消息推送到队列的后面。然而，这又引发了另一个问题，即消息将不同步，并且推送到 api 的数据已过期。

我认为您的关注是必要的，但服务总线不会将您的消息传递给 DLQ，此时，主要问题与您的 API/服务的可用性有关。您需要监控 API/服务的运行状况。