我们有一个包含200K+条消息的服务总线(标准计划(队列。我们想以2k-5K为一批从服务总线读取消息，并使用Azure函数(每30分钟(将其分批插入SQL Db。
大多数情况下，ReceiveMessagesAsync会返回几百条消息，有时会变为个位数。我知道maxMessages参数不能保证按摩次数，但我仍然想知道是否有任何方法可以优化它，使其返回至少50%的最大消息次数。
现在，我在循环中使用ReceiveMessagesAsync，一旦我有5K行以上，就点击Db，以减少Db调用的数量。如果有任何其他选项可以优化此过程，请推荐。
var receivedMessages = await serviceBusReceiver.ReceiveMessagesAsync(maxMessages: 5000, maxWaitTime: TimeSpan.FromSeconds(1));
找到的预回迁设置为5k。我增加了电话号码，但无济于事。
- 使用的包：Azure.Messaging.ServiceBus
- 版本：7.4.0.Net
- 框架：.Net 6
简短的版本是否定的，目前没有办法保证返回的消息数量最少。
附加上下文
当请求消息时，优先顺序是快速将数据返回到应用程序，这样收到的消息的锁就不会在等待填充批处理所需的附加消息时过期，这样应用程序就不会闲置。
客户端向网络传输请求所需的批处理大小，网络传输尝试在预取和网络流的约20毫秒窗口内构建完整的批处理，然后返回当前可用的任何消息。如果您指定的maxWaitTime中没有可用的消息，则不会返回任何消息。
预取可以通过使更多的消息可用于批处理来提供帮助，但它们必须通过网络进行流式传输。根据消息的大小，流式传输可能需要一点时间来填充预取缓存，如果您消耗消息的速度快于网络流式传输的速度，则缓存将耗尽。
预取的一个重要考虑因素是要记住，预取缓存中保存的消息被服务锁定，如果使用得不够快，这些锁定将过期。
想法和下一步
在您的场景中，应用程序似乎能够以比网络更快的速度消耗和处理消息以保持缓存满。
如果你的目标是最大限度地减少数据库调用，那么将预取设置为你的批量大小，并将几个接收调用中的消息收集到一个5000条的批量中，可能是最简单、最安全的方法。根据你满足批量大小的速度，你可能需要续订你持有的消息的锁。
另一个可能的选择，尽管我不会这么做，是考虑增加预取，并在接收调用之间引入延迟，让缓存重新填充；这里的挑战是，您无法了解自己负责的消息锁，并且无法续订锁，因此它不那么可靠。