【服务总线 Azure Service Bus】Service Bus在使用预提取(prefetching)后出现Microsoft.Azure.ServiceBus.MessageLockLostException异常问题

问题描述

Service Bus接收端的日志中出现大量的MessageLockLostException异常。完整的错误消息为：

问题原因

在接收方使用预提取后，Service Bus服务将锁定此次预提取的消息。通过锁定操作，其他接收方则无法接收到此预提取的消息(保持消息唯一消费)。如果接收方在锁定过期之前无法完成此消息，则该消息便对其他接收方可用。

预提取的消息的副本则保留在缓存中。 使用过期的缓存副本的接收方会在尝试完成该消息时接收到一个异常(MessageLockLostException)。 

默认情况下，消息锁定在 30 秒后过期。 这一值可延长到 5 分钟。 通常在创建队列时进行设置。 这是队列级别的属性，不能在消息基础上进行更改。如下图中的Message lock duration（可以点击Change Link进行修改）.

解决问题

方法一：修改Message Lock Duration的时间长度，最大可以修改到5分钟。

方法二：在设定消息CompleteAsync前，判断时间 

message.LockedUntilUtc中的时间是否已经超过了Message Lock Duration，如果消息未到期但即将到期，可通过调用RenewLock，延续和扩展又一默认锁定时间段

if(message.LockedUntilUtc.Minute <= 1)
message.RenewLock();

扩展问题

1：既然预提取更快，为何不是默认选项？（https://docs.azure.cn/zh-cn/service-bus-messaging/service-bus-prefetch#if-it-is-faster-why-is-prefetch-not-the-default-option）

预提取可加快消息流程，方法是在应用程序请求消息时及请求消息前，准备好消息用于本地检索。 这种吞吐量提升是应用程序作者不得不明确作出的某种权衡的结果：

通过 ReceiveAndDelete 接收模式，预提取缓存区获取的所有消息在队列中不再可用，仅驻留在内存中预提取缓存区，直到应用程序通过 Receive/ReceiveAsync 或 OnMessage/OnMessageAsync API 接收到它们 。 如果在应用程序接收到消息前终止应用程序，这些消息将丢失，且不可恢复。

在 PeekLock 接收模式下，提取到预提取缓存区的消息将以锁定状态进入缓存区，并且将超时时钟用于锁定计时。 如果预提取缓存区很大，且处理所需时间过长，以致消息锁定在驻留于预提取缓存区，甚至应用程序还在处理消息时就到期，可能出现一些令人困惑的事件要应用程序处理。 如MessageLockLostException

如果消息处理需要高度的可靠性，且处理需要大量精力和时间，则建议谨慎使用或者丝毫不用预提取功能。

如果需要较高吞吐量且消息处理通常比较便宜，则预提取会产生显著的吞吐量优势。

参考资料

Windows Azure MessageLockLostException ： https://stackoverflow.com/questions/15303711/windows-azure-messagelocklostexception

使用服务总线消息传递改进性能的最佳实践： https://docs.azure.cn/zh-cn/service-bus-messaging/service-bus-performance-improvements?tabs=net-standard-sdk#prefetching