先执行redis-cli CLIENT LIST，重点检查omem（输出缓冲区内存）、oll（待发消息数）和cmd（最后命令）；omem接近硬限且oll>0即确认输出缓冲区满，而非盲目调参。

怎么看是不是输出缓冲区真满了

别一上来就改配置，先确认问题根源。执行 redis-cli CLIENT LIST，重点盯三个字段：omem（输出缓冲区内存占用，单位字节）、oll（待发送消息条数）、cmd（最后执行的命令）。

• omem 接近或超过你设的硬限（比如 client-output-buffer-limit pubsub 第一个值），且 oll > 0 → 基本就是它了
• omem 长期为 0，但连接频繁断 → 可能根本没成功 SUBSCRIBE，或客户端已断开未重连
• oll 很大但 omem 很小 → Redis 正在往 socket 写，卡在客户端读取或网络层

怎么快速揪出吃内存的订阅者

用这条命令筛出 omem > 1MB 的异常连接：

redis-cli CLIENT LIST | awk -F' ' '{for(i=1;i1000000) print "omem=" omem, "cmd=" cmd}' | sort -k1,1nr | head -10

• 输出里 cmd=subscribe 或 cmd=（空）且 omem 持续在 8–30MB → 典型慢消费订阅者
• cmd=monitor 且 omem 稳定几 MB → 客户端没读响应，或中间网络卡住
• omem=0 但 qbuf 很大 → 问题在输入侧，和输出缓冲区无关

为什么调小 client-output-buffer-limit 反而更危险

设成 pubsub 8mb 2mb 30 看似“更严格”，实则容易触发雪崩：

Sentinal Redis

监控Redis服务器健康状况、内存、性能及BullMQ队列。检查队列深度、失败任务，分析慢查询并诊断问题。

下载

• 慢订阅者每 30 秒被踢一次，若客户端无退避重连逻辑，立刻重连+重订阅 → 缓冲区从头填满
• 旧连接的 omem 内存不会秒释放，可能滞留数十秒；新连接又开始分配 → “踢一个、来两个、积三倍”
• 结果是 used_memory_rss 比 used_memory 高出 2 倍以上，瞬时内存尖峰直接 OOM
• 集群中还会放大：一个节点抖动 → 多个客户端重连 → 其他节点缓冲区也跟着涨

调整 client-output-buffer-limit 的安全姿势

硬限、软限、超时时间必须配合，不能只加数字：

• pub/sub 场景：先观察峰值 omem（比如稳定在 12MB），设为 pubsub 64mb 16mb 120 —— 给足余量，延长软限时间
• normal 场景（如 pipeline 或 monitor）：避免用 0 0 0，推荐 normal 512mb 128mb 60 —— 允许突发，但连续 60 秒超 128MB 就断
• slave 场景：RDB 2GB、带宽 20MB/s → 传输至少需 100 秒，time 参数必须 ≥ 120；软限建议设为 RDB 大小的 1.5 倍（如 3GB）
• 改完务必同步写入 redis.conf，否则重启后恢复默认值

缓冲区调大只是兜底，真正要查的是客户端有没有正确释放连接、复用是否混乱、消费逻辑是否阻塞 —— 这些不解决，再大的缓冲区也撑不了几天。