必须显式配置client-output-buffer-limit，否则redis 6.2集群因三重角色叠加（normal/pupsub/slave）导致缓冲区风险指数级放大，慢订阅、大key返回或主从同步卡顿均可能直接触发oom。
Redis 6.2 集群不能靠默认值防崩溃，必须为 normal、pubsub、slave 三类显式配置 client-output-buffer-limit，否则慢订阅、大 key 返回或主从同步卡顿都会直接触发 OOM。
为什么集群节点比单机更怕输出缓冲区失控
集群中每个节点既是普通服务端（处理客户端请求），又可能是其他节点的 slave（参与分片复制），还可能被业务用作 pubsub 中心。三重角色叠加，缓冲区风险不是线性增长，而是指数级放大：
- 一个
pubsub连接卡住 → 单节点omem暴涨 → 主线程阻塞 → 其他客户端响应延迟 → 更多连接堆积 → 整个分片不可用 - 某个 shard 的 slave 同步慢 →
client-output-buffer-limit slave触发断连 → 重试全量同步 → 主节点内存瞬时冲高 → 可能拖垮同机器上其他 Redis 实例（若混部） - 集群 gossip 流量本身不走输出缓冲区，但 client 命令如
CLUSTER NODES或批量MGET落在大 slot 上，会压满normal缓冲区，尤其 pipeline 场景下
Redis 6.2 集群必须改的三项配置（写死在 redis.conf）
Redis 6.2 不支持 CONFIG SET client-output-buffer-limit 动态修改，所有值必须落盘生效。以下配置需在每个集群节点的 redis.conf 中明确写出，不能依赖默认或注释掉：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
client-output-buffer-limit normal 64mb 32mb 120：适用于含 pipeline 或监控类客户端（如redis-cli --bigkeys）。硬限 64MB 防止单次LRANGE huge-list 0 -1崩溃；软限 32MB 持续 120 秒才断，给慢网络留余量 -
client-output-buffer-limit pubsub 32mb 8mb 60：6.2 默认是8mb 2mb 60，对真实业务太激进。若消息平均 50KB、最多 20 订阅者、容忍积压 3 秒，理论峰值约 3MB，设 8MB 软限已足够；硬限 32MB 是为突发毛刺兜底 -
client-output-buffer-limit slave 512mb 256mb 300：集群中 slave 连接来自其他节点，RDB 可能达数百 MB。硬限必须 > 预估最大 RDB 体积 × 1.5（例如 RDB 300MB → 设 512MB），且不能超过该节点maxmemory的 30%
改完配置后不 kill slave 连接等于白配
Redis 加载新配置后，**已存在的连接仍沿用旧缓冲区策略**。集群中最容易被忽略的是那些长期存活的 slave 连接（比如某节点刚完成 failover，新 master 还在同步旧数据）：
- 执行
redis-cli CONFIG REWRITE确保配置落盘 - 用
redis-cli CONFIG GET client-output-buffer-limit核对三行值是否正确加载 - 对所有 flags=S（slave）的连接，必须运行
redis-cli CLIENT KILL TYPE slave强制重连——这是让新slave限值生效的唯一方式 - 对 pubsub 连接，无法批量 kill，需协调业务侧滚动重启订阅客户端，或等其自然断连重连（依赖心跳超时）
上线前必须盯住的两个指标
配置不是设完就稳了。Redis 6.2 集群里，真正危险的信号藏在实时连接状态里，而不是 INFO memory：
- 用
redis-cli CLIENT LIST | grep -E 'omem=[1-9][0-9]{6,}'找出omem > 1MB的连接，再结合cmd=subscribe或flags=S定位问题类型 - 关注
client_longest_output_list—— 这个值持续 > 1000 说明有连接的输出链表已严重积压，主线程正在忙于写 socket，此时即使内存没爆，响应延迟也已不可控
缓冲区问题从来不是“会不会爆”，而是“哪条连接先爆、爆完会不会引发雪崩”。6.2 集群里，一个没 kill 的旧 slave 连接，可能就是整组分片抖动的起点。
