ServiceStack.Redis:PooledRedisClientManager和RedisManagerPool等待上一请求完成 [英] ServiceStack.Redis: PooledRedisClientManager and RedisManagerPool waits for prev req to finish

问题描述

我正在测试Redis的全双工"通信，如此处显示，并阅读文档，我认为PooledRedisClientManager和RedisManagerPool有一个客户端池，因此能够并行处理多个MQ消息.

I am testing out the Redis "full duplex" communication as shown here, and reading the docs, I thought that the PooledRedisClientManager as well as RedisManagerPool have a pool of clients, and thus being able to process several MQ messages in parallel.

但是，在测试项目在Github上找到，在我看来，这是并非如此，否则我正在丢失某些东西.该解决方案包括:

However, in the test project, found here on Github, it seems to me that this is not the case, or I am missing something. The solution consists of:

• EventPublisher:.NET Core WinForms应用程序，用于将Hello DTO发布到MQ
• EventConsumer:.NET Core WinFOrms应用程序，具有用于处理Hello DTO的Service impl

我在HelloService Any(Hello req)中添加了一个Thread.Sleep，当我从EventPublisher中快速发送多个Hello DTO时，我期望它们将在EventConsumer中并发处理，因为我认为将使用客户端池.但是，事实似乎并非如此.

I added a Thread.Sleep inside the HelloService Any(Hello req) and when I from the EventPublisher send several Hello DTOs quickly, I was expecting them to be handled concurrently in the EventConsumer, as I thought the pool of clients would be used. This, however, doesn't seem to be the case.

HelloResponse在似乎相同的线程上一个接一个地处理.请观看以下短片:

The HelloResponses are handled one after the other, on the same thread it seems. Please take a look at this short video:

http://somup.com/cYheY8iNml

在这里，我快速地将三个Hello DTO触发到MQ，然后在VS的输出"窗口中，您可以看到三个DTO相互处理.

Here, I fire off three Hello DTOs to the MQ in quick succession, and in the Output window in VS, you can see that the three DTOs are handled one after each other.

我在PooledRedisClientManager或RedisManagerPool中都没有找到可以指定池大小的设置.

I did not find a setting in PooledRedisClientManager nor RedisManagerPool where I could specify the pool size.

推荐答案

我认为PooledRedisClientManager和RedisManagerPool都有一个客户端池

I thought that the PooledRedisClientManager as well as RedisManagerPool have a pool of clients

这句话是真的.

，因此能够并行处理多个MQ消息.

and thus being able to process several MQ messages in parallel.

这是一个无效的结论，没有上下文就没有意义.合并的 Redis客户端管理器本身不执行任何执行，即它们仅管理Redis客户端池，这意味着从池中检索客户端时:

This is an invalid conclusion that's meaningless without context. The Pooled Redis Client Managers do not do any execution themselves, i.e. they only manage a pool of redis clients meaning when a client is retrieved from the pool:

var redis = clientsManager.GetClient();

从客户端管理器管理的客户端池中检索了RedisClient(即，单个TCP连接的客户端与Redis服务器的连接)，并且在处置该客户端时，该客户端将返回到池中，而不是终止TCP连接.

The RedisClient (i.e. single TCP connected client to redis server) was retrieved from a pool of clients managed by the client manager and that when the client is disposed, it's returned to the pool instead of the TCP connection being terminated.

当某事正在使用某个池，客户端管理器不自行执行Redis命令以及应用程序使用该操作特定于其实现的情况时，就可以假设所有这些.他们使用的池无关紧要，可以很容易地将它们配置为使用 BasicRedisClientManager 不使用任何池的情况，即应用程序对客户端管理器的使用不会对使用方式进行任何假设.

That's all that can be assumed when something is using a pool, the Client Managers don't execute Redis commands by themselves, and what the application does that uses it is specific to their implementation. The fact that they're using a pool is irrelevant, they could easily be configured to use the BasicRedisClientManager where no pool is used, i.e. an Application's use of a client manager doesn't make any assumption of how it's being used.

在示例项目中，您正在使用 Redis MQ 执行ServiceStack服务:

In your example project you're using Redis MQ to execute your ServiceStack Services:

mqHost.RegisterHandler<Hello>(base.ExecuteMessage);
mqHost.Start(); //Starts listening for messages

在您的上一个答案中，您引用:

创建一个Redis MQ服务器，该服务器在其自己的后台线程上处理每个消息.

Creates a Redis MQ Server that processes each message on its own background thread.

完整的评论继续提供一个示例:

The full comment goes on to provide an example:

i.e. if you register 3 handlers it will create 7 background threads:
///   - 1 listening to the Redis MQ Subscription, getting notified of each new message
///   - 3x1 Normal InQ for each message handler
///   - 3x1 PriorityQ for each message handler (Turn off with DisablePriorityQueues)

其中解释了Redis MQ Server如何处理消息，即每种消息类型都是在其自己的后台线程上处理的，因此，如果您阻塞消息工作线程，那么您将阻塞用于阻塞该类型的其他消息的线程(即，请求DTO) .

Which explains how Redis MQ Server processes messages, i.e. each message Type is processed on its own background Thread, so if you block the message worker thread then you're blocking thread for blocking other messages for that Type (i.e. Request DTO).

mqHost.RegisterHandler<Hello>(base.ExecuteMessage);

它不会阻止在自己的后台线程或优先级MQ线程上处理过的其他消息，这些消息将通过Priority>0发送的该类型的消息进行处理.

It doesn't block other messages which are processed on their own background thread or the Priority MQ thread for that Type processing messages sent with Priority>0.

Redis MQ docs提供了一个示例，说明如何通过在注册处理程序时指定noOfThreads来增加用于处理每种消息类型的线程数:

The Redis MQ docs provides an example of how you can increase the number of threads used to process each message type by specifying the noOfThreads when registering the handler:

RedisMqServer还支持为单个请求生成任意数量的后台线程，因此如果发布到Twitter是一项IO密集型操作，则只需分配2个或更多工作线程即可将吞吐量提高一倍，例如:

The RedisMqServer also supports spawning any number of background threads for individual requests, so if Posting to twitter was an IO intensive operation you can double the throughput by simply assigning 2 or more worker threads, e.g:

mqService.RegisterHandler<PostStatusTwitter>(ExecuteMessage, noOfThreads:2);
mqService.RegisterHandler<CallFacebook>(ExecuteMessage);
mqService.RegisterHandler<EmailMessage>(ExecuteMessage);

这篇关于ServiceStack.Redis:PooledRedisClientManager和RedisManagerPool等待上一请求完成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！