Azure Service Bus队列消息停留时间过长，多Pod运行仍延迟求因

问题背景 #

我们有一个订阅Azure Service Bus Topic的.NET进程，存在消息在队列中停留时间过长的问题。当前Azure Service Bus配置为2个消息单元（Messaging Units），服务使用率不高，但消息无法被及时拾取；不同队列的消息锁定时长（Message Lock duration）设置为10-30秒。

该.NET代码运行在AKS集群上，使用Azure.Messaging.ServiceBus库，代码示例如下：

ServiceBusClient client = new ServiceBusClient("connectionString",new ServiceBusClientOptions());

ServiceBusProcessorOptions clientOptions = new ServiceBusProcessorOptions
            {
                AutoCompleteMessages = false
            };

ServiceBusProcessor processor = client.CreateProcessor("topicName", "subscription", clientOptions);

processor.ProcessMessageAsync += ProcessMessageHandler;
processor.ProcessErrorAsync += ProcessErrorHandler;

processor.StartProcessingAsync();

即便运行多个Pod，消息在队列中的停留时间仍过长，以下是导致该延迟的潜在原因分析：

附带Service Bus遥测及使用率截图：

潜在原因分析 #

1. 处理器并发数配置过低 #

默认情况下，ServiceBusProcessor的MaxConcurrentCalls参数值为1，意味着每个处理器实例一次只能处理1条消息。即便部署多个Pod，如果每个Pod内的处理器并发数未调整，整体消息处理吞吐量无法提升，会直接导致消息堆积在队列中。

2. 手动消息完成逻辑存在阻塞或遗漏 #

由于设置了AutoCompleteMessages = false，必须在ProcessMessageHandler中手动调用message.CompleteAsync()完成消息生命周期。如果：

• 消息处理逻辑本身耗时过长、发生IO阻塞
• 代码遗漏调用完成方法
• 异常未被正确捕获导致完成逻辑未执行

都会导致消息长期处于锁定状态，锁过期后重新回到队列，反复循环拉长整体停留时间。

3. 预取（Prefetch）配置不合理 #

默认预取数量较低时，处理器需要频繁向Service Bus服务端请求消息，增加了网络往返延迟。未合理调整ServiceBusProcessorOptions.PrefetchCount参数，会降低消息拾取的效率。

4. AKS Pod资源限制或调度异常 #

如果Pod被设置了严格的CPU、内存资源限制，导致.NET进程无法高效运行；或者AKS集群节点资源不足、调度策略限制导致Pod无法及时启动/调度，都会影响消息处理器的运行状态，导致消息无法被及时拾取。

5. 会话或分区配置不匹配 #

若订阅启用了会话（Session）功能，但处理器未正确实现会话消息的处理逻辑，会导致特定会话的消息堆积；另外，若订阅未启用分区，在消息量集中时单分区的处理能力可能成为瓶颈（当前使用率不高，该可能性较低）。

6. 网络或连接池问题 #

AKS集群与Azure Service Bus之间存在网络延迟、丢包，或者客户端连接池配置不合理（如连接数不足、连接复用率低），会导致处理器无法快速建立连接获取消息，增加消息在队列中的停留时间。

7. 消息锁定时长与处理耗时不匹配 #

如果消息处理的平均耗时接近或超过设置的锁定时长，消息会在处理完成前就过期解锁，重新回到队列，导致重复处理和停留时间延长。需根据实际处理耗时调整锁定时长，或在处理过程中调用message.RenewLockAsync()延长锁的有效期。

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