调小client-output-buffer-limit pubsub反而更危险，因断连后旧omem内存滞留数十秒，若客户端无退避重连逻辑，将引发“踢-连-积-踢”循环，导致used_memory_rss飙升、大量连接omem卡在8–30mb不降。
client-output-buffer-limit 配置改小反而更危险
调小 client-output-buffer-limit pubsub 参数（比如从默认的 32mb 8mb 60 改成 8mb 2mb 30）不会让系统更稳，反而容易触发 OOM。Redis 在缓冲区超限时会强制断开客户端，但断连不等于内存立刻释放——尤其在 pub/sub 场景下，旧连接的 omem 可能滞留数十秒；若客户端无退避重连逻辑，新连接马上又开始堆积，形成“踢-连-积-踢”循环。
典型表现是：used_memory_rss 比 used_memory 高出 2 倍以上，client_longest_output_list 持续 >1MB，且 redis-cli CLIENT LIST 中大量连接的 omem 卡在 8–30MB 不下降。
真正安全的起点仍是默认值：client-output-buffer-limit pubsub 32mb 8mb 60。除非你确认所有订阅者都能在 60 秒内稳定消费、且单次消息体不超过 8MB，否则别动它。
如何定位哪个 client 在吃光输出缓冲区
别只看 INFO memory，要直接查每个连接的实时缓冲区占用。关键字段是 omem（输出缓冲区字节数）和 cmd（最后执行命令），再按 omem 排序：
redis-cli CLIENT LIST | grep -E 'omem|cmd' | awk '{print $1,$7,$13}' | sort -k2 -nr | head -10
常见高 omem 场景包括：
- Java 项目用 Lettuce 共享一个
StatefulRedisPubSubConnection订阅多个频道，一个频道消费慢拖垮整条连接 - Python 里用全局
redis.Redis()实例调用subscribe()，不同模块互相干扰 - 客户端未显式调用
unsubscribe()或close()，尤其在 Serverless 函数中短生命周期服务反复启停
订阅者处理慢时，不能只靠调大缓冲区
把 client-output-buffer-limit 改成 128mb 32mb 300 是饮鸩止渴。缓冲区只是临时容器，不是消息队列。真正的问题是：消息来了没人及时取走。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
必须从架构上隔离风险：
- 每个业务逻辑（如订单通知、用户登录广播）使用独立的连接池，禁止混用
- 发布端采用 List + Pub/Sub 混合模式：先
LPUSH queue:order_events data，再PUBLISH channel:order_updated 1；顺序不能反 - 订阅端启动时先
LRANGE queue:order_events 0 -1补读历史，处理完再LTRIM queue:order_events 0 -1清空（或用LTRIM queue:order_events -100控制长度）
这种模式下，即使订阅者掉线重连，也能通过 List 补漏，Pub/Sub 只负责轻量通知。
服务端 timeout 和 tcp-keepalive 必须协同配置
Redis 默认 timeout 300（5 分钟空闲即断连）+ tcp-keepalive 0（禁用内核保活），对纯等待消息的 pub/sub 连接极不友好。空闲连接大概率被中间网络设备静默切断，而客户端毫无感知。
必须同时设置：
-
CONFIG SET timeout 600（拉长到 10 分钟，给客户端留出心跳与重连窗口） -
CONFIG SET tcp-keepalive 60（每 60 秒发一次 ACK 探测，快速发现 NAT/防火墙/LB 断连） - 两项都写入
redis.conf并执行CONFIG REWRITE或重启生效，否则重启即丢
客户端还要配应用层心跳（如 Lettuce 的 pingBeforeActivateConnection=true + 异常监听后手动 ping()），否则 TCP 层活着、协议层已僵死的情况无法识别。
缓冲区溢出本质是消费能力与发布节奏失配，不是参数调优问题。最易被忽略的是：pub/sub 连接断开后，旧 omem 内存不会立刻释放，而新连接又在建——这个时间差才是 OOM 真正爆发点。
