Azure Service Bus SubscriptionClient高延迟/无法并发接收消息问题

看起来你遇到的是Service Bus订阅客户端默认配置下的吞吐量瓶颈问题——默认的OnMessageAsync模式如果没做优化，确实会出现每条消息处理间隔较大的情况，主要原因是客户端每次处理完一条才会向服务端请求下一条，加上网络往返的时间，就会累积出明显的延迟。下面是几个针对性的优化方案：

1. 开启并配置预取（Prefetch Count） #

预取是Service Bus客户端的核心优化手段之一，它能让客户端一次性从服务端拉取多条消息到本地缓存，这样处理完一条后直接从本地缓存取下一条，省去了每次都和服务端交互的网络延迟。

你只需要在创建订阅客户端后设置PrefetchCount，建议设置为和你单次发送的消息数量匹配（或者根据你的处理能力调整）：

var factory = MessagingFactory.CreateFromConnectionString("your-connection-string");
var subscriptionClient = factory.CreateSubscriptionClient("MyTopicName", "MySubscriptionName");
// 设置预取数量，比如和发送的10条一致
subscriptionClient.PrefetchCount = 10;

2. 启用并发消息处理 #

如果你的消息处理逻辑是线程安全的，可以通过设置OnMessageOptions的MaxConcurrentCalls来允许客户端同时处理多条消息，这样不仅能减少单条消息的间隔，还能提升整体的处理吞吐量。

示例代码：

var options = new OnMessageOptions
{
    // 根据你的系统资源和处理能力调整，比如设置为5
    MaxConcurrentCalls = 5,
    AutoComplete = true // 如果你希望处理完自动完成消息，否则需要手动调用CompleteAsync
};

subscriptionClient.OnMessageAsync(async message =>
{
    // 你的消息处理逻辑
    Console.WriteLine($"Received message: {message.MessageId}");
    // 如果AutoComplete为false，需要手动完成
    // await message.CompleteAsync();
}, options);

3. 优化发送端的批量发送 #

你当前的发送端是循环调用SendAsync，每次发送一条消息，这会导致消息分批到达服务端。改用SendBatchAsync批量发送，能让消息更紧凑地推送到订阅端，减少消息在服务端的排队间隔：

var factory = MessagingFactory.CreateFromConnectionString("your-connection-string");
var sender = factory.CreateMessageSender("MyTopicName");

var messages = new List<BrokeredMessage>();
for (int i = 0; i < 10; i++)
{
    messages.Add(new BrokeredMessage($"Message {i}") { MessageId = $"Msg-{i}" });
}

// 批量发送
await sender.SendBatchAsync(messages);

补充说明 #

• 预取数量不要设置得过大，否则会占用过多的客户端内存，而且如果消息处理时间很长，预取的消息会一直被锁定，导致其他客户端无法获取（如果有多个订阅的话）。
• 并发处理时一定要确保你的消息处理逻辑是线程安全的，比如不要共享非线程安全的资源，否则会出现数据混乱的问题。
• 如果使用PeekLock模式（默认模式），要注意消息的锁定超时时间，如果处理时间超过锁定时间，消息会重新回到队列，导致重复处理，必要时可以调用RenewLockAsync延长锁定时间。

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