我们有一个python grpc(grpcio with asyncio(服务器，它对redis PUB/SUB(使用aioredis 2.x(消耗的数据进行服务器端流传输，每个流最多可组合25个通道。在低流量的情况下，一切都很好，一旦我们达到2000多个并发流，消息的传递就开始落后。
一些设置细节和我们迄今为止尝试的内容：
-
到GRPC的客户端连接在带有Ingress NGINX控制器的kubernetes集群上进行负载平衡，而且扩展(我们尝试了9个pod，每个pod有10个进程实例(似乎根本没有帮助(负载平衡是均匀分布的(。
-
我们正在运行一个五节点的redi7.x集群，每个副本有96个线程。
-
当GRPC落后时，使用CLI客户端连接到redis-当GRPC流落后于时，单个通道准时
-
消息的大小很小(40B(，每个流的可变速率在每秒20-200之间。
-
Aioredis似乎正在为每个pubsub订阅者打开一个新的连接，即使我们为每个grpc实例使用有上限的连接池。
-
内存/CPU的利用率不像网络I/O那样显著，所以我们在方面没有受到瓶颈
-
使用Rust编写的非常相似的grpc服务器尝试了相同的设置，结果相似
@mike_t，正如您在评论中提到的，从Redis-Pub/Sub切换到zmq有助于解决问题。
ZeroMQ(也称为websphere MQ、0MQ或zmq(是一个开源的通用消息库，看起来像一个可嵌入的网络库，但起到了并发框架的作用。它为您提供了在各种传输(如进程内、进程间、TCP和多播(上承载原子消息的套接字。
您可以使用扇出、pub-sub、任务分发和请求回复等模式将套接字连接到N到N。它足够快，可以成为集群产品的面料。它的异步I/O模型为您提供了可扩展的多核应用程序，这些应用程序是作为异步消息处理任务构建的。
它有许多语言API，并在大多数操作系统上运行。