NestJS场景下单ioredis客户端多Redis PubSub通道订阅相关问题咨询

1、单个订阅客户端是否通过单条Redis连接实现多路复用？ #

是，ioredis 库的普通订阅客户端（非集群模式）默认会复用单条TCP连接处理所有通道的订阅、取消订阅操作，以及接收所有已订阅通道的推送消息，属于天然的多路复用实现。
需要注意的是，进入订阅状态的Redis连接无法执行PubSub体系外的其他命令（比如读写普通缓存键），所以一般业务项目都会单独拆分订阅专用客户端、普通操作客户端两个独立实例。
如果你的项目用的是Redis集群模式，ioredis的集群订阅客户端会默认给每个集群主节点建立独立的订阅连接，从上层调用来看还是单个客户端实例，底层是多连接适配集群的PubSub广播机制。

2、单个客户端可支持的通道订阅数量是否存在上限？ #

Redis本身没有对单个连接的订阅通道数做硬编码的固定上限，实际可支持的订阅数和集群扩容没有直接关联，主要受以下几个因素限制：

• Redis服务端的客户端输出缓冲区限制：默认配置下client-output-buffer-limit pubsub 32mb 8mb 60，如果单个订阅连接需要推送的消息总量超过32MB硬限制，或者连续60秒超过8MB软限制，服务端会主动断开该连接
• 内存占用：每个订阅的通道会在服务端、客户端各占用少量内存存储订阅关系，当订阅量级达到十万、百万级别时，会出现明显的内存占用增长，达到机器内存上限后会触发OOM
• 消费性能：如果订阅的通道消息量过大，客户端消费速度跟不上，会导致消息在服务端缓冲区堆积，很快触发前面提到的输出缓冲区限制，导致连接断开

普通业务场景下，单通道消息量不大、消费逻辑足够高效的前提下，单个客户端实例支持几千到几万级别的订阅是没有问题的，更高量级可以测试后再做评估。

内容的提问来源于stack exchange，提问作者Nowa Concordia