Redis将所有要发送给客户端的数据先放入输出缓冲区，客户端读取速度越慢，缓冲区积压就越多。当某个客户端长时间不读取数据，比如一个阻塞的订阅者或一个慢速的从库，输出缓冲区可能无限增长，最终耗尽Redis的可用内存，导致服务崩溃。client-output-buffer-limit就是专门用来控制这种风险的配置项，它能为不同类型的客户端单独设定缓冲区上限，超过限制后Redis会主动断开连接，释放内存。
这个参数并不是一个全局开关，而是按客户端类别分别配置的。Redis将客户端分为三类：普通客户端（normal）、从库客户端（slave）和发布订阅客户端（pubsub）。每一类都可以设置独立的硬限制、软限制和软限制持续时间。理解这三个值的含义是正确配置的前提，下面我们先从参数结构说起。
client-output-buffer-limit参数详解
该参数的完整语法为：client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>。其中class可以是normal、slave或pubsub。硬限制（hard limit）是一个绝对的字节数，如果输出缓冲区大小超过这个值，Redis会立即关闭客户端连接。软限制（soft limit）也是一个字节数，但允许输出缓冲区在软限制之上保持一段时间，这个时间由soft seconds指定。如果缓冲区大小超过软限制的时间超过了soft seconds秒，Redis同样会断开连接。
这种“软硬结合”的设计非常巧妙：硬限制防止瞬间暴涨直接打爆内存；软限制则给了客户端一个缓冲时间，允许短暂的消息堆积，但不会让堆积无限持续。如果软限制设为0，表示不启用软限制，只使用硬限制。如果硬限制也设为0，则表示不限制该类型客户端的输出缓冲区。
默认配置下，Redis对普通客户端是不限制的（normal 0 0 0），因为普通客户端通常执行命令后立即读取回复，缓冲区不会长期积压。但从库客户端和发布订阅客户端默认有较严格的限制。下面是一个典型的redis.conf配置示例：
# 普通客户端不限制 client-output-buffer-limit normal 0 0 0 # 从库客户端：硬限制256MB，软限制64MB，软限制持续时间60秒 client-output-buffer-limit slave 256mb 64mb 60 # 发布订阅客户端：硬限制32MB，软限制8MB，软限制持续时间60秒 client-output-buffer-limit pubsub 32mb 8mb 60
需要注意的是，单位可以是b、k、kb、m、mb、g、gb，不区分大小写。例如64mb表示64兆字节。在生产环境中，这些数值需要根据实际数据量和网络状况调整，不能盲目照搬。
不同客户端类型的配置策略
普通客户端（normal）通常执行简单的读写命令，回复数据量小，读取速度快，发生缓冲区积压的概率较低。但如果应用程序有bug，比如执行了一个返回大量数据的命令却不读取结果，就可能让普通客户端的输出缓冲区持续增长。对于普通客户端，建议设置一个相对较小的硬限制，比如32mb或64mb，软限制可以设得更低一些，软限制持续时间30秒左右。这样既能防止个别异常客户端占用过多内存，又不会影响正常请求。
从库客户端（slave）的情况更加复杂。主从复制过程中，主库需要把写命令发送给从库，如果从库处理速度跟不上，主库的输出缓冲区就会积压。这个缓冲区的大小直接影响复制延迟和主库内存占用。如果设置得太小，可能导致从库频繁断开重连，甚至无法完成全量同步；设置得太大，又可能让一个慢从库拖垮主库。一般来说，全量同步阶段需要较大的缓冲区，因此硬限制可以适当放宽到256mb甚至512mb，软限制可以设为64mb，软限制持续时间60秒。但具体数值应该根据主库写入量和从库性能综合评估。
发布订阅客户端（pubsub）的输出缓冲区风险最高。订阅者可能长时间不在线读取消息，而发布者持续产生消息，缓冲区会迅速膨胀。对于pubsub客户端，建议设置相对小的硬限制和软限制，例如硬限制32mb，软限制8mb，软限制60秒。如果消息量很大，可以适当提高硬限制，但必须对订阅者的消费能力有清晰认识。一个常见的做法是监控每个pubsub客户端的输出缓冲区使用情况，必要时手动断开或告警。
实际场景与调优建议
要判断当前的client-output-buffer-limit配置是否合理，需要监控输出缓冲区的实际使用情况。可以通过INFO clients命令查看总体的客户端连接数和被断开连接数，或者使用CLIENT LIST命令查看每个客户端的详细信息，其中omem字段表示输出缓冲区当前使用的内存字节数。如果发现某些客户端的omem持续接近或超过硬限制，说明配置可能过小；如果omem长期远低于限制，则可以考虑适当收紧以节省内存。
调整client-output-buffer-limit时，要避免两个极端：一是设置过大，起不到保护作用，内存溢出风险依然存在；二是设置过小，导致正常客户端频繁被断开，影响业务可用性。特别是对于从库客户端，过小的限制会造成复制中断，从库不断重连，主库不断尝试重新同步，反而增加系统负载。建议先用默认值运行一段时间，观察omem的峰值和增长趋势，再根据实际情况逐步调整。
另外，client-output-buffer-limit与maxmemory策略需要配合使用。即使输出缓冲区限制合理，如果Redis整体内存已经达到maxmemory上限，并且没有合适的淘汰策略，新写入仍然可能失败，或者触发主动断开客户端。因此，在配置输出缓冲区限制的同时，也要规划好maxmemory和淘汰策略，确保Redis实例的内存使用处于可控范围。
最后，如果遇到因为输出缓冲区超限导致客户端断开的问题，除了调整限制参数，还可以从业务侧优化：比如减少单个命令的返回数据量、提高客户端读取频率、使用管道或批量操作等。对于发布订阅场景，可以考虑使用消息队列替代Redis pubsub，或者为订阅者设置更积极的消费逻辑，从根源上减少缓冲区积压。
掌握client-output-buffer-limit的配置方法，本质上是在可用性和内存安全之间寻找平衡。没有一套放之四海皆准的数值，需要结合业务特点、数据规模和监控数据持续优化。只要理解了硬限制、软限制和软限制时间的作用机制，就能在面对内存告警时快速定位问题，做出合理调整。
Redisclient-output-buffer-limit内存溢出修改时间：2026-08-19 23:54:55