根本原因是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数量几乎不变——这是输出缓冲区失控的典型指纹，比日志报错更早暴露问题
