控制Azure Service Bus队列消息接收 [英] Control Azure Service Bus Queue Message Reception

问题描述

我们有一个分布式体系结构，并且有一个本地系统需要调用.挑战在于系统的容量不可扩展，并且无法同时承担更多的请求负载.我们已经实现了服务总线队列，其中有一个消息处理程序正在侦听此队列并调用本机系统.当前的挑战是，每当一条消息发布到队列中时，消息处理程序就会立即处理该请求.但是，我们希望有一个方案，一次只能处理两个请求.选择两个，对其进行处理，然后继续进行下两个.Service Bus Queue是否提供内置选项来控制此操作，还是我们只能使用自定义逻辑?

We have a distributed architecture and there is a native system which needs to be called. The challenge is the capacity of the system which is not scalable and cannot take on more load of requests at same time. We have implemented Service Bus queues, where there is a Message handler listening to this queue and makes a call to the native system. The current challenge is whenever a message posted in the queue, the message handler is immediately processing the request. However, We wanted to have a scenario to only process two requests at a time. Pick the two, process it and then move on to the next two. Does Service Bus Queue provide inbuilt option to control this or should we only be able to do with custom logic?

var options = new MessageHandlerOptions()
            {
                MaxConcurrentCalls = 1,
                AutoComplete = false
            
            };
        client.RegisterMessageHandler(
            async (message, cancellationToken) =>
            {
                try
                {
                    //Handler to process
                    await client.CompleteAsync(message.SystemProperties.LockToken);
                }
                catch
                {
                    await client.AbandonAsync(message.SystemProperties.LockToken);
                }

            }, options);

推荐答案

消息处理程序API专为并发而设计.如果您想在任何给定的时间点处理两条消息，那么最大并发数为2的Handler API将是您的答案.如果您需要在任何给定的时间点处理一批两条消息，则不需要此API.相反，您可以使用Mikolaj提供的答案中概述的较低级别的API来构建自己的消息泵.

Message Handler API is designed for concurrency. If you'd like to process two messages at any given point in time then the Handler API with maximum concurrency of two will be your answer. In case you need to process a batch of two messages at any given point in time, this API is not what you need. Rather, fall back to building your own message pump using a lower level API outlined in the answer provided by Mikolaj.

请谨慎对待重新锁定消息.这不是保证操作，因为它是客户端操作，并且如果有通信网络，当前，经纪人将重置锁定，并且如果您向外扩展，消息将被另一个竞争的消费者再次处理.这就是为什么在您的方案中进行横向扩展可能会成为一个挑战.

Careful with re-locking messages though. It's not a guaranteed operation as it's a client-side operation and if there's a communication network, currently, the broker will reset the lock and the message will be processed again by another competing consumer if you scale out. That is why scaling-out in your scenario is probably going to be a challenge.

关于接收多个消息时， MessageReceiver 的较低级API的其他要点- ReceiveAsync(n)不会不确保将检索 n 条消息.如果绝对必须有 n 条消息，则需要循环以确保有 n 条，并且不少.

Additional point is about lower level API of the MessageReceiver when it comes to receiving more than a single message - ReceiveAsync(n) does not guarantee n messages will be retrieved. If you absolutely have to have n messages, you'll need to loop to ensure there are n and no less.

关于管理客户端和获取队列消息计数的最后一点-强烈建议不这样做.管理客户端不适合在运行时频繁使用.相反，它用于偶尔的呼叫，因为这些呼叫非常慢.鉴于您最终可能会遇到一个处理端点，而一次只能约束两个消息(甚至不是每秒)，因此这些调用将增加总的处理时间.

And the last point about the management client and getting a queue message count - strongly suggest not to do that. The management client is not intended for frequent use at run-time. Rather, it's uses for occasional calls as these calls are very slow. Given you might end up with a single processing endpoint constrained to only two messages at a time (not even per second), these calls will add to the overall time to process.

这篇关于控制Azure Service Bus队列消息接收的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！