Redis订阅者卡住主因是客户端未启用非阻塞I/O；应使用事件循环多路复用，避免单连接阻塞、万级连接瓶颈及PSUBSCRIBE的O(N)匹配开销，且Pub/Sub无消息确认与持久化。
Redis 订阅者卡在 subscribe 后没反应？多半是客户端没启用非阻塞 I/O
Redis 的发布订阅（Pub/Sub）本身不支持“批量订阅”或“后台监听”，subscribe 命令一发，连接就进入阻塞状态，只能等消息。如果用同步客户端（比如 Python 的 redis-py 默认配置）逐个调用 subscribe，不仅吞吐低，还容易因单连接卡住导致整个订阅逻辑停滞。
真正能扛住海量频道（比如上万 channel）的方案，必须让一个连接持续接收多 channel 消息，且不被某条慢消费拖垮。核心不是 Redis 侧调优，而是客户端能否把 socket 置为非阻塞 + 配合事件循环做多路复用。
- Python 推荐用
redis-py的PubSub对象配合run_in_thread(blocking=False)，或直接用asyncio+aioredis（注意 v2.x 已弃用，v2.0+ 用redis包的Redis.from_url(..., decode_responses=True)+pubsub()） - Node.js 必须用
ioredis，它原生基于net.Socket并自动管理readable事件，比原生redis模块更适合高并发订阅 - Go 用
github.com/go-redis/redis/v9，它的Subscribe返回*PubSub，内部已用 goroutine + channel 处理多路消息分发，无需手动轮询
为什么不能对每个频道起一个独立连接？
表面上看，“一个 channel 一个连接”逻辑清晰，但实际会迅速触达系统瓶颈：
- Linux 默认单进程最大文件描述符数通常为 1024，订阅 5000 个 channel 就得开 5000 连接，必然
EMFILE: too many open files - Redis 服务端也有
maxclients限制（默认 10000），大量空闲订阅连接会挤占真实业务连接资源 - 每个 TCP 连接都有内存开销（内核 socket buffer、客户端缓冲区），万级连接光内存就吃掉几百 MB
-
PING/PONG心跳、超时重连逻辑在万级连接下变成调度灾难，极易引发雪崩式重连
正确做法是：用 1～N 个连接（N 通常 ≤ CPU 核数），每个连接通过 subscribe channel1 channel2 channel3 ... 一次性订阅数百个 channel，再靠客户端事件循环分发。
PSUBSCRIBE 和 SUBSCRIBE 的性能差异有多大？
很多人以为通配符订阅（PSUBSCRIBE logs.*）更省事，但代价明确：
- Redis 内部对
PSUBSCRIBE使用单独的字典（pubsub_patterns），匹配走的是链表遍历，O(N) 时间复杂度；而SUBSCRIBE的 channel 查找是哈希表 O(1) - 每个消息发布时，Redis 不仅要投递给所有
SUBSCRIBE的精确 channel，还要遍历全部pubsub_patterns做 glob 匹配——channel 越多、pattern 越复杂，发布延迟越高 - 实测：当有 1000 个
PSUBSCRIBEpattern 时，单条PUBLISH耗时从 0.1ms 升至 3ms+；而同等数量的SUBSCRIBE几乎无感
结论：除非业务强依赖动态 channel 名（如用户 ID 生成的实时流），否则一律用 SUBSCRIBE + 预定义 channel 列表，避免模式匹配开销。
如何安全地动态增减订阅的 channel？
生产环境常需热更新订阅列表（比如新增监控指标、下线废弃 topic），但 SUBSCRIBE/UNSUBSCRIBE 不是原子批量操作，直接调用易丢消息或状态错乱。
- 不要在运行中反复
UNSUBSCRIBE再SUBSCRIBE：中间窗口可能漏收消息，且 Redis 不保证命令执行顺序与消息到达顺序一致 - 推荐做法：客户端维护本地 channel 白名单，新 channel 直接发
SUBSCRIBE（Redis 允许多次订阅同一 channel，无副作用）；旧 channel 先发UNSUBSCRIBE，但保留接收能力直到确认该 channel 最后一条消息已处理完毕 - 关键细节：
UNSUBSCRIBE后 Redis 仍会推送已入队但未读取的消息，所以客户端必须消费完缓冲区再彻底关闭对应 handler——redis-py的parse_response(block=False)或ioredis的psubscribe事件回调里加计数器可辅助判断
最易被忽略的一点：Redis Pub/Sub 没有消息确认、没有持久化、不保证投递，任何网络抖动或客户端崩溃都会导致消息丢失。真需要可靠传递，请换用 Kafka 或 RabbitMQ，别硬撑。
