公有云Redis的发布订阅连接断开是因client-output-buffer-limit pubsub默认值过小导致缓冲区溢出被踢，需通过消息拆分、轻量序列化、消费者代理、频道收敛及合理配置客户端参数来规避。
公有云 Redis 实例的发布订阅连接数不是被“限制”了，而是被 client-output-buffer-limit pubsub 主动踢掉的——不配置它，就等于没设防。
为什么 CLIENT LIST 里大量 omem 持续上涨还连不上？
公有云 Redis（如阿里云、腾讯云、AWS ElastiCache）默认不显式配置 client-output-buffer-limit pubsub，实际生效的是隐式继承值（比如 8mb 2mb 60），但这个值完全没考虑你的消息体积和消费延迟节奏。
- 你发一条 150KB 的订单事件，下游消费卡住 4 秒 → 单连接缓冲区涨到 600KB
- 10 个 tab 同时订阅同一频道 → 理论积压 6MB，已逼近软上限
- 若此时还有网络抖动或 HTTP 调用超时，
omem很快突破硬限，Redis 主动close连接，客户端重连又触发新缓冲分配 → 内存尖峰 + 频繁断连 - 公有云控制台通常不暴露
omem监控，你只能靠redis-cli CLIENT LIST | grep subscribe手动排查
如何在不改云厂商配置的前提下绕过限制？
公有云 Redis 多数不支持直接修改 redis.conf 或执行 CONFIG SET client-output-buffer-limit（该命令对 pubsub 类型根本无效）。必须换思路：
- 把大消息拆小：
PUBLISH event:order:created不传完整订单对象，只传{"id":"ord_abc123","version":2}，业务侧按需查库或拉取详情 - 用轻量协议替代 JSON：
MessagePack序列化后体积降 50%，同样积压时长下缓冲区压力减半 - 加一层消费者代理：用自建
redis-py订阅者常驻进程，收到消息后异步分发给 Webhook 或 MQ，避免浏览器/移动端直连 Redis - 强制频道收敛：禁用
user:123:notifications这类带 ID 的动态频道，统一走event:user:notify+ 消息体过滤，减少频道 dict 内存占用
连接池和客户端参数怎么配才不踩坑？
很多人以为“多开几个订阅连接=高可用”，其实反而加速触发缓冲区溢出。关键不是数量，是每个连接的可控性：
-
redis-py客户端必须关掉health_check_interval（默认 0，即关闭），否则心跳会干扰subscribe长连接状态 - 不要复用普通读写连接池做
SUBSCRIBE——ConnectionPool的max_connections是全局的，pubsub 连接一旦堆积，会挤占其他命令资源 - 每个前端页面只维持 1 个
SUBSCRIBE连接，用PSUBSCRIBE event:*+ 客户端过滤，而不是为每个业务模块开独立连接 - 设置
socket_timeout=30（非3或5），避免因短暂网络抖动导致连接被误判为死链而重建
真正难的不是算出 client-output-buffer-limit pubsub 16mb 4mb 120 这组数字，而是让所有下游消费方稳定在“平均 200ms 内处理完一条消息”的节奏上——缓冲区只是安全垫，不是缓存池。
