本文介绍了优化批处理模式下从Azure Service Bus接收消息的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
我们有一个包含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，当前无法保证返回的邮件数量最少。
其他上下文
当请求消息时，优先顺序是快速将数据返回到您的应用程序，以便已收到的消息的锁定不会在等待填充批处理所需的其他消息时到期，并且您的应用程序不会处于空闲状态。
maxWaitTime内没有可用消息，则不会返回任何内容。Prefetch可以通过为批处理提供更多消息来提供帮助，但它们必须通过网络流式传输。根据消息的大小，可能需要一点时间才能流入足够多的预取缓存，如果您使用消息的速度快于网络可以传输它们的速度，则缓存将耗尽。
预回迁的一个重要注意事项是要记住，预回迁缓存中保存的消息是由服务锁定的，如果使用得不够快，这些锁定将会过期。
想法和下一步
在您的方案中，应用程序使用和处理消息的速度似乎比网络传输消息以保持缓存已满的速度更快。
另一种可能的选择(尽管我不会这样做)是考虑增加预取并在接收调用之间引入延迟以让缓存重新填充；这里的挑战是您无法看到您负责的消息锁，并且将无法续订锁，因此它将不那么可靠。
这篇关于优化批处理模式下从Azure Service Bus接收消息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！
本站部分内容来源互联网,如果有图片或者内容侵犯您的权益请联系我们删除！