Azure ServiceBus队列/订阅的竞争消费者是否应采用轮询机制？

嘿，你的测试结果完全符合Azure Service Bus的预期行为，咱们来拆解下背后的逻辑，以及怎么解决低负载下大部分实例空闲的问题：

为什么会出现这种差异？ #

Azure Service Bus的消息分配逻辑和MaxConcurrentCalls、预取机制（哪怕你没显式设置PrefetchCount，SDK也有默认处理逻辑）直接相关：

• 当MaxConcurrentCalls > 1时：客户端相当于告诉Service Bus“我能同时处理多条消息”，服务端会优先把可用消息分配给这个“能力更强”的客户端。尤其是低负载场景下，消息总量少，这个客户端一次性就能把所有消息拉走处理，自然其他实例就没消息可拿了。
• 当MaxConcurrentCalls = 1时：每个客户端一次只能处理一条消息，处理完才会向服务端请求下一条。这时候Service Bus的负载均衡机制会启动，把消息轮流分给不同的消费者，所以你会看到交替分配的情况。

怎么让横向扩展的实例都动起来？ #

如果想在低负载下也让多个实例参与处理，同时保留高并发能力，可以试试这几个调整方向：

1. 显式设置合理的PrefetchCount：
   • 别把预取数设得太大（比如别超过MaxConcurrentCalls的2倍太多），不然单个客户端会拉走大量消息，其他实例只能干等。
   • 建议把PrefetchCount设为MaxConcurrentCalls的1-2倍，这样既保证并发处理的效率，又不会让单个客户端垄断消息池。
2. 配合消息锁时长调整：
   • 确保队列/订阅的LockDuration设置合理，既要足够让客户端处理完消息，又别太长导致消息被一个客户端长时间占着。如果锁过期，消息会回到队列，其他实例就有机会接手了。
3. 换成更现代的SDK：
   • 旧的SubscriptionClient是.NET Framework时代的产物，新的ServiceBusProcessor（属于Azure.Messaging.ServiceBus包）有更智能的负载均衡策略，默认就能更好地在多个实例间均衡消息分配，更适合横向扩展的场景。

给你个新SDK的简单配置参考：

var processor = client.CreateProcessor("你的订阅名称", new ServiceBusProcessorOptions
{
    MaxConcurrentCalls = 5, // 你需要的并发处理数
    PrefetchCount = 10, // 预取数设为并发数的2倍
    MaxAutoLockRenewalDuration = TimeSpan.FromMinutes(5)
});

总结 #

你观察到的现象是Service Bus消息分配机制的正常表现，核心在于客户端的并发能力会影响服务端的消息分配决策。通过调整预取策略、优化锁时长，或者升级到新SDK，就能有效解决低负载下大部分实例空闲的问题，实现更均衡的横向扩展。

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