优化批处理模式下从Azure Service Bus接收消息 [英] Optmize receiving messages from Azure Service Bus in batch mode

问题描述

我们有一个包含200K+消息的服务总线(标准计划)队列。我们希望以2K-5K的大小从服务总线读取消息，并使用Azure函数(每30分钟)将其批量插入到SQL DB中。

大多数情况下，ReceiveMessagesAsync会返回几百条消息，有时会达到一位数。我确实理解MaxMessages参数不能保证消息计数，但我仍然想知道是否有任何方法可以优化它，使其返回至少50%的最大消息计数。

现在，我在循环中使用ReceiveMessagesAsync，并在拥有5K+行时访问数据库，以减少数据库调用的数量。请推荐是否有任何其他选项来优化此流程。

var receivedMessages = await serviceBusReceiver.ReceiveMessagesAsync(maxMessages: 5000, maxWaitTime: TimeSpan.FromSeconds(1));

找到的预回迁设置为5k。我增加了数量，但无济于事。

• 使用的包：Azure.Messaging.ServiceBus
• 版本：7.4.0.net
• 框架：.NET 6

推荐答案

简写版本为no，当前无法保证返回的邮件数量最少。

其他上下文
当请求消息时，优先顺序是快速将数据返回到您的应用程序，以便已收到的消息的锁定不会在等待填充批处理所需的其他消息时到期，并且您的应用程序不会处于空闲状态。

客户端向网络传输发出所需批处理大小的请求，网络传输尝试在从预取和网络流开始的大约20毫秒窗口内构建完整批处理，然后再返回当前可用的任何消息。如果在您指定的maxWaitTime内没有可用消息，则不会返回任何内容。

Prefetch可以通过为批处理提供更多消息来提供帮助，但它们必须通过网络流式传输。根据消息的大小，可能需要一点时间才能流入足够多的预取缓存，如果您使用消息的速度快于网络可以传输它们的速度，则缓存将耗尽。

预回迁的一个重要注意事项是要记住，预回迁缓存中保存的消息是由服务锁定的，如果使用得不够快，这些锁定将会过期。

想法和下一步
在您的方案中，应用程序使用和处理消息的速度似乎比网络传输消息以保持缓存已满的速度更快。

如果您的目标是最大限度地减少数据库调用，那么将预取设置为您的批处理大小并将来自多个接收调用的消息收集到一批5,000条消息中可能是最简单、最安全的方法。根据您满足批处理大小的速度，您可能需要续订您持有的邮件的锁定。

另一种可能的选择(尽管我不会这样做)是考虑增加预取并在接收调用之间引入延迟以让缓存重新填充；这里的挑战是您无法看到您负责的消息锁，并且将无法续订锁，因此它将不那么可靠。

这篇关于优化批处理模式下从Azure Service Bus接收消息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！