Azure服务总线的最大吞吐量如何确保累积100条消息而不是仅读取
如何确保仅当收集到 n 条消息时才从队列中读取消息。我们有什么办法可以确保这一点吗？
我相信必须存在 ServiceBusProcessorOptions 来确保这一点。我正在使用设置为 100 的 MaxConcurrentCalls。但是当也有一条消息时我会收到消息。
How can I ensure to read message from queue only when n number of messages are collected. Do we have anything to ensure that.
I believe something must be there ServiceBusProcessorOptions to ensure this. I am using MaxConcurrentCalls which is set to 100. But I get message when there is one message also.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简而言之，没有，目前没有办法保证返回的消息数量最少。
MaxConcurrentCalls控制一次可以发生多少个处理程序的活动调用。事实上，数字越大，每个处理程序调用看到批次中消息数量越少的机会就越大。100 对于此设置来说是一个巨大的值，并且可能会由于线程池中的争用而导致问题，除非您的计算机具有 32 个以上可用内核。
其他背景
当请求消息时，优先级是快速将数据返回到应用程序，以便已接收消息的锁不会在等待填充批次所需的其他消息时过期，并且应用程序不会闲置。
处理器向网络传输请求所需的批量大小，网络传输尝试在返回当前可用的任何消息之前从预取和网络流的约 20 毫秒窗口内构建完整的批量。如果在您指定的
maxWaitTime内没有可用消息，则不会返回任何内容。预取可以通过使更多消息可供批处理使用来提供帮助，但它们必须通过网络流式传输。根据消息的大小，可能需要一些时间才能流入足够的空间来填充预取缓存，如果您消耗消息的速度比网络传输消息的速度快，则缓存将耗尽。
预取的一个重要考虑因素是要记住，预取缓存中保存的消息已被服务锁定，如果没有足够快地消耗这些锁，这些锁将会过期。
The short version is no, there is not currently a way to guarantee the minimum number of messages returned.
MaxConcurrentCallsgoverns how many active invocations of your handlers can happen at a single time. In fact, the higher the number, the greater the chance that each handler call sees a smaller number of messages in a batch.100 is a huge value for this setting and is likely to cause problems due to contention in the thread pool unless you have a machine with 32+ cores available.
Additional Context
When messages are requested, the prioritization is to return data to your application quickly so that the locks for the messages that have been received do not expire waiting for the additional messages needed to fill the batch, and so that your application doesn't sit idle.
The processor makes the request for the desired batch size to the network transport, which attempts to build a full batch within a ~20 millisecond window from prefetch and the network stream before returning whatever messages are currently available. If no messages are available within the
maxWaitTimethat you've specified, nothing is returned.Prefetch can help by making more messages available to the batch, but they have to be streamed in over the network. Depending on the size of messages, it can take a bit to stream in enough to fill the prefetch cache and if you're consuming messages faster than the network can stream them, the cache will run dry.
An important consideration for prefetch is to remember that messages held in the prefetch cache are locked by the service, and those locks will expire if they are not consumed quickly enough.