Azure.Messaging.ServiceBus SDK：接收前能否判断消息是否锁定？

结论先行：Peek操作返回的LockedUntil属性确实不可靠，这并非SDK或Service Bus的Bug，而是Peek本身的设计特性导致的。

原因解析 #

• Peek是只读快照操作：Service Bus为保证性能，Peek获取的是消息的缓存快照，不会实时同步消息的最新锁定状态。这意味着返回的LockedUntil可能是历史数据，或者消息刚被锁定/解锁时，快照还未更新，从而出现默认值或过期时间的情况。
• 锁定状态的动态性限制：消息的锁定状态会随时间（超时解锁）或接收者操作（主动解锁/完成）实时变化，Peek的机制决定了它无法提供实时准确的锁定状态信息。

替代解决方案 #

如果想避免ReceiveMessageAsync因无可用消息而等待，可采用以下方案：

1. 调整等待时间参数：将ReceiveMessageAsync的maxWaitTime设为TimeSpan.Zero，这样队列中无可用消息时，方法会立刻返回null，无需等待。
2. 用队列运行时属性估算可接收消息数：通过ServiceBusAdministrationClient.GetQueueRuntimePropertiesAsync获取队列的ActiveMessageCount（活跃消息总数）和LockedMessageCount（已锁定消息数），两者差值可作为当前可接收消息的近似值。该值是统计近似值，存在一定延迟，但比Peek的LockedUntil可靠。
3. 依赖原生机制自动处理：无需提前检查锁定状态，让ReceiveMessageAsync按默认逻辑工作。Service Bus会自动处理锁定超时的消息，解锁后重新变为可接收状态，无需人工干预。

内容的提问来源于stack exchange，提问作者Alasdair Stark