Redis发布订阅卡顿主因是客户端消费能力不足或连接资源耗尽，而非Redis服务端性能瓶颈；需隔离连接池、改用异步驱动+批处理+超时熔断，并在需可靠性时迁移到Stream。
Redis发布订阅卡顿是客户端撑不住，不是Redis扛不住
高并发下Pub/Sub卡顿，90%以上的情况不是Redis服务器性能瓶颈，而是客户端消费能力不足或连接资源耗尽。Redis的Pub/Sub本身是内存级广播，不落盘、无ACK、无重试，只要消息能发出去，服务端就认为完成。真正卡在消费者收不到、处理慢、连接被挤掉——比如Python的redis-py默认用单线程阻塞listen()，Java里没配对的Subscription生命周期管理，或者大量客户端共用一个连接却没做连接复用。
内核参数调优只对“连接风暴”有效，别乱改net.core.somaxconn
当每秒新建成百上千个Pub/Sub连接（比如微服务频繁启停、客户端未复用连接），可能触发SYN queue overflow或accept() failed (24: Too many open files)。这时才需要调整内核参数：
-
net.core.somaxconn：设为 65535（默认常为128），避免TCP握手队列溢出 -
fs.file-max：系统级文件句柄上限，建议 ≥ 200000 -
net.ipv4.tcp_fin_timeout：从60降到30，加快TIME_WAIT回收（仅当大量短连场景）
注意：net.core.rmem_max和wmem_max对Pub/Sub影响极小——订阅者读的是socket buffer，但Redis发完即丢，buffer堆积说明消费者已经堵死，调大只会掩盖问题，不解决吞吐。
连接池必须按“订阅通道”隔离，不能全局复用一个Pool
Pub/Sub连接是独占式状态机：一个连接只能subscribe多个channel，但一旦执行unsubscribe或psubscribe，内部状态会切换；若多个业务模块共享同一连接池，极易出现channel错订、消息漏收、甚至ConnectionError: Connection closed by server。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
正确做法是按业务域划分连接池：
- 每个独立的订阅逻辑（如订单通知、库存变更）使用专属
ConnectionPool - Python中禁用
redis.Redis(connection_pool=shared_pool)用于Pub/Sub，改用redis.Redis(connection_pool=order_pool) - Java用Lettuce时，为不同
StatefulRedisPubSubConnection配置独立ClientResources，避免共享event loop线程
否则你会看到日志里反复出现READONLY You can't write against a read only replica——那其实是连接被其他模块误发了PUBLISH导致状态混乱。
消费延迟高？换异步驱动 + 批处理 + 超时熔断
阻塞式listen()在高吞吐下必然积压。必须把“接收”和“处理”解耦：
- Python用
redis-py的parse_response(block=True, timeout=0.1)轮询，配合queue.Queue投递给工作线程 - Java用Lettuce的
RedisPubSubReactiveCommands+Flux流式消费，避免线程阻塞 - 每批最多取10–50条消息做批量处理（如批量写DB），避免单条消息处理超时拖垮整个loop
- 加
timeout兜底：比如3秒内没收到新消息，主动unsubscribe并重建连接，防长连接假死
最容易被忽略的一点：Pub/Sub没有消息确认机制，如果消费者进程崩溃，消息就彻底丢失。真要可靠，得切到Stream + XGROUP，别硬扛Pub/Sub。
