根本原因是client-output-buffer-limit pubsub触发强制断连，因订阅连接输出缓冲区（omem）超限被redis主动关闭；需按单条消息体积×并发订阅数×容忍积压秒数推算合理值，如120kb×8×5≈4.8mb，设soft-limit 6mb、hard-limit 16mb、soft-seconds≥45，并写入redis.conf+config rewrite生效。

为什么SUBSCRIBE连接总被Redis主动断开

根本不是网络抖动或密码错误，而是client-output-buffer-limit pubsub触发了强制断连。Redis对每个订阅连接单独维护输出缓冲区，发布者不等消费者读取就直接复制消息进缓冲区；一旦某个前端页面卡住、服务端HTTP调用超时、或WebSocket心跳漏发，omem字段就会持续上涨，超限即杀——不重试、不告警、直接断。

怎么算出合理的pubsub hard-limit和soft-limit值

别抄网上“32mb 8mb 60”，这数字没代入你的业务数据。真实值必须从三要素推导：单条消息平均体积 × 最大并发订阅数 × 可容忍积压秒数：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 你的订单更新消息JSON后约 120KB，前端最多开 8 个tab订阅同一频道，允许消费逻辑卡住 5 秒 → 理论积压 = 120KB × 8 × 5 ≈ 4.8MB
• soft-limit 设 6mb（留20%余量），hard-limit 设 16mb（防突发毛刺）
• soft-seconds 必须 > 客户端心跳间隔；若用 redis-py 的 ping_interval=30，则至少设 45

配置写在哪、怎么生效、最容易漏哪步

client-output-buffer-limit pubsub 必须写死在 redis.conf 里，CONFIG SET 动态修改无效，改完不重启等于白改：

• 在配置文件中添加明确行：client-output-buffer-limit pubsub 16mb 6mb 45（顺序不能错）
• 执行 CONFIG REWRITE 持久化，避免重启丢失
• 对已存在的订阅连接，必须手动执行 CLIENT KILL TYPE pubsub，否则它们继续按旧规则跑
• 检查是否生效：运行 redis-cli CLIENT LIST | grep subscribe，确认 omem 字段不再无限制上涨

上线后必须盯住的两个信号

配置不是一劳永逸，真正危险的是“看起来正常但正在缓慢堆积”：

• omem 值长期稳定在 5MB 以上，说明软限太松或消费延迟已常态化，得调低 soft-seconds 或查下游I/O瓶颈
• INFO memory 中 used_memory_human 忽然飙升，但 db0:keys 数量几乎不变——这是输出缓冲区失控的典型指纹，比日志报错更早暴露问题