必须显式配置client-output-buffer-limit，否则普通客户端无输出缓冲区上限，易致内存耗尽；需为normal、pubsub等类型分别设置hard/soft限制，尤其pubsub缓冲区最易失控。
client-output-buffer-limit 配置项必须显式设置
Redis 默认对普通客户端不设输出缓冲区上限，这意味着一旦客户端消费慢（比如 SUBSCRIBE 后不及时读取 PUBLISH 消息），client-output-buffer 会持续增长，最终可能吃光内存或触发 maxmemory 驱逐甚至 OOM kill。
必须在 redis.conf 中为每类客户端显式配置 client-output-buffer-limit，否则等于没限制：
-
normal：普通命令响应（如 GET、LRANGE 返回大量数据） -
slave：主从复制中从节点的输出缓冲（已弃用，新版用repl-backlog管理） -
pubsub：订阅模式下未读取的频道消息
示例配置：
client-output-buffer-limit normal 0 0 0 client-output-buffer-limit pubsub 32mb 8mb 60
注意三个参数顺序固定：hard-limit soft-limit soft-seconds。设为 0 表示禁用对应限制（不推荐）。
pubsub 缓冲区最容易失控，必须单独盯紧
PUB/SUB 是输出缓冲区爆炸的高发场景——发布者完全不感知消费者状态，一条 PUBLISH 可能往多个慢订阅者的缓冲区各塞一份副本。哪怕只有一两个客户端卡住，几秒内就能积压百 MB。
典型错误现象：CLIENT LIST 显示某 client 的 omem 字段持续上涨，且 cmd 为 subscribe 或 psubscribe；同时 INFO memory 中 used_memory_human 异常升高，但 dbX 键数量无变化。
实操建议：
- 把
pubsub的hard-limit设为明确值（如32mb），避免无限堆积 -
soft-limit和soft-seconds要配合业务心跳周期：例如客户端每 30 秒 ping 一次，就设soft-seconds为45，防止误杀 - 上线前用
redis-cli --csv CLIENT LIST | grep pubsub定期检查活跃订阅者缓冲区大小
normal 类型缓冲区限制要区分同步/异步调用场景
普通客户端的输出缓冲区膨胀通常发生在两类操作中：大 key 全量返回（如 LRANGE biglist 0 -1）、或 pipeline 中响应积压。但限制方式不能一刀切。
关键区别：
- 同步调用（如单次
GET大 value）：缓冲区峰值 = 单次响应体积，hard-limit应略大于最大可能响应（如 10MB value → 设 12MB） - pipeline 批量请求：缓冲区需容纳所有未读响应，若发 100 个
HGETALL，每个返回 50KB，则需至少 5MB 缓冲 —— 此时soft-limit触发更关键，避免瞬时 burst 被断连
常见坑：client-output-buffer-limit normal 1mb 512kb 10 在 pipeline 场景下极易触发断连，因为 10 秒内只要累积超 512KB 就开始踢人。生产环境建议 normal 的 hard-limit 至少设为 16–64MB，soft-limit 关闭（即设 0）或大幅放宽。
限制生效后客户端被强制断开，但不会报错提示
当输出缓冲区突破 hard-limit，Redis 会直接关闭连接，且不发送任何错误响应。客户端看到的现象通常是“连接意外中断”或 “Connection reset by peer”，日志里也看不到 Redis 主动断连记录。
排查要点：
- 用
CLIENT LIST查看目标 client 的omem和idle字段：如果omem接近配置的hard-limit且idle很大，基本可确认是缓冲区被踢 - 检查 Redis 日志是否有
Client X disconnected after hitting output buffer limit（需开启loglevel verbose） - 客户端代码里必须处理连接闪断：重连 + 重订阅（PUB/SUB 场景下还要考虑消息丢失补偿）
最易被忽略的一点：限制只作用于**连接生命周期内的缓冲区累计值**，不区分命令类型。一个慢消费者在 SUBSCRIBE 后又执行了几个大响应命令，所有输出都算进同一个 omem，所以 pubsub 和 normal 的限制必须分开配，不能指望共用一套阈值。
