必须显式配置client-output-buffer-limit pubsub，因默认值不匹配业务实际，且CONFIG SET不支持动态修改；需根据消息体积、并发订阅数和可容忍积压时长计算hard/soft限值，禁用限制（0 0 0）将导致内存失控。
client-output-buffer-limit pubsub 配置为什么必须显式设置
Redis 默认对 pubsub 客户端的 client-output-buffer-limit 有内置值（如 8mb 2mb 60），但这个“默认”仅在未配置时生效，且不同版本/编译选项下可能不一致；更重要的是，它不考虑你的业务吞吐、消息体积和消费延迟节奏。不显式配置等于放弃控制权——一旦某个订阅者卡住 3 秒，100KB/秒的消息就能让单个连接缓冲区涨到 300KB；100 个这样的连接就占掉 30MB，还没算频道名 dict 开销。
关键点：
-
client-output-buffer-limit必须写在redis.conf里，CONFIG SET不支持动态修改该参数 - 设为
0 0 0表示禁用限制，等同于主动放弃内存保护 -
normal类型默认不限制是合理的（请求-响应模式天然可控），但pubsub是服务器单向推送，必须单独盯紧
如何计算合理的 pubsub hard-limit 和 soft-limit 值
别套用网上“32mb 8mb 60”的通用配置。真实值要从你自己的数据来：单条消息平均体积 × 最大并发订阅数 × 可容忍积压时长。
例如：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 你的订单状态更新消息经 JSON 序列化后平均
120KB - 前端页面最多同时打开 8 个 tab 订阅同一频道，即最多
8个活跃订阅者 - 你允许消费逻辑最慢卡住
5秒（比如含一次数据库查表） - 那么理论最大积压 =
120KB × 8 × 5 ≈ 4.8MB→soft-limit设6mb较稳妥 -
hard-limit建议设为16mb，留出突发毛刺余量，且明确非零（禁用=危险） -
soft-seconds必须 > 客户端心跳间隔；若你用redis-py的ping_interval=30，则至少设45
CLIENT LIST 中 omem 持续上涨说明什么
执行 redis-cli CLIENT LIST 后，重点关注 omem= 字段（不是 qbuf）和 cmd= 字段：
-
omem=1245678且cmd=subscribe：该连接已订阅但长期没读消息，缓冲区正在堆积 -
omem值 > 1MB 就该预警，> 5MB 很可能即将被踢或已拖慢主线程 - 若大量连接
omem突然同步上涨，大概率是某类消息体积突增，或下游消费逻辑卡在 I/O（如 HTTP 调用超时） - 注意：
omem占用的内存不会因连接断开立刻释放，尤其在频繁重连场景下，旧缓冲区残留 + 新连接分配会引发瞬时内存尖峰
调小 client-output-buffer-limit 反而引发 OOM 的原因
把 client-output-buffer-limit pubsub 8mb 2mb 60 改成 4mb 1mb 30 看似更“严格”，但实际可能触发恶性循环：
- 软限制时间从 60 秒缩到 30 秒，网络抖动或短暂 GC 就可能误判为“持续超限”，导致批量断连
- 客户端若无指数退避重连逻辑，会在断开后立即重试
SUBSCRIBE，瞬间重建上百连接 - 旧连接的输出缓冲区内存尚未完全回收，新连接又各自分配缓冲区，
used_memory_rss瞬间飙升 - 此时
INFO memory会显示used_memory_human暴涨，但db0键数量不变，mem_fragmentation_ratio异常高
真正有效的做法是：先定位高 omem 连接来源（比如某个前端 SDK 版本有 bug），再配合服务端限流与客户端降级，而不是单纯压低 buffer 限额。
