必须显式配置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 限额。