Azure 服务总线队列消息处理 [英] Azure Service Bus queue message handling

问题描述

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

So I have an azure function acting as a queue trigger that calls an internally hosted API.

在线似乎没有关于如何处理由于有毒以外的问题而无法处理的消息的明确答案.

There doesn't seem to be a definitive answer online on how to handle a message that could not be processed due to issues other than being poisonous.

示例:

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

My message is received and the function attempts to call the API. The message payload is correct and could be handled however the API/service is down for whatever reason (this time will likely be upwards of 10 minutes). Currently what happens is the message delivery count is reaching its max(10) and then getting pushed to the dead letter queue, which in turn happens for each message after.

我需要一种方法，要么不增加交付计数，要么在达到最大值时重置它.或者，我可以放弃对消息的窥视锁定而不增加传递计数，因为我想停止处理队列中的任何消息，直到 API/服务恢复运行.这样我就可以确保所有可以处理的消息都不会因为服务之间的连接问题而陷入僵局.

I need a way to either not increment the delivery count or reset it upon reaching max. Alternatively I could abandon the peek lock on the message without increment the delivery count as I want to stop processing any message on the queue until the API/service is back up and running. This way I would ensure that all messages that can be processed will be and will not fall on the dead letter because of connection issues between services.

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

Any ideas on how to achieve this?

推荐答案

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

Currently what happens is the message delivery count is reaching its max(10) and then getting pushed to the dead letter queue, which in turn happens for each message after.

作为这个 文档 关于Exceeding MaxDeliveryCount 的说明:

As this document states about Exceeding MaxDeliveryCount:

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

Queues and subscriptions have a QueueDescription.MaxDeliveryCount/SubscriptionDescription.MaxDeliveryCount setting; the default value is 10. Whenever a message has been delivered under a lock (ReceiveMode.PeekLock), but has been either explicitly abandoned or the lock has expired, the message's BrokeredMessage.DeliveryCount is incremented. When the DeliveryCount exceeds the MaxDeliveryCount, the message gets moved to the DLQ specifying the ``MaxDeliveryCountExceeded``` reason code.

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

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

According to your requirement, I assumed that you could follow the approaches below to achieve your purpose:

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

• For receiving messages under ReceiveMode.PeekLock

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

You could specify the Maximum Delivery Count between 1 and 2147483647 under the "SETTINGS > Properties" of your service bus queue on Azure Portal.

用于在ReceiveMode.ReceiveAndDelete下接收消息

For receiving messages under ReceiveMode.ReceiveAndDelete

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

You could try-catch the exception when your API/service is down, then you could re-send the message to your queue.

这篇关于Azure 服务总线队列消息处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！