引入

• 什么是缓冲区：用一块内存空间来暂时存放命令数据，以免出现因为数据和命令的处理速度慢与发送速度而导致的数据丢失和性能问题
• 但是问题是，因为缓冲区的内存空间是有限的，如果往里面写入数据的速度大于从里面读取数据的速度，就会导致缓存需要越来越多的内存来暂存数据，当缓冲区占用的内存超出了设置的上限阈值时，就会出现缓冲区溢出。缓冲区溢出就会导致数据丢失
• 那是不是调大上限阈值就可以了呢？不是的，如果缓冲区占用的内存空间太大，一旦耗尽了redis实例上的可用内存，那么就会导致redis实例崩溃

redis服务器中哪些地方用到了缓冲区

主要有两个场景：

• 在客户端和服务器之间进行通信时，用于暂存客户端发送的命令数据，或者服务端返回给客户端的数据结果
• 在主从节点进行数据同步时，用来暂存主节点接收的写命令和数据

服务器端和客户端之间的缓冲区

为了避免客户端和服务端的请求发送和处理速度不匹配，服务端给每个连接的客户端都设置了一个输入缓存区和输出缓冲区。

• 输入缓冲区会先把客户端发送过来的命令暂存起来，redis主线程再从输入缓冲区中读取命令，进入处理。
• 当redis主线程处理完数据之后，会把结果写入到输出缓冲区，再通过输出缓冲区返回给客户端

如何应对输入缓冲区溢出

输入缓冲区是用来暂存客户端发送的请求命令的，所以可能导致溢出的情况主要有两种：

• 写入了bigkey。比如一下子写入了多个百万级别的集合类型数据
• 服务端处理请求的速度过慢。比如，redis主线程出现了间歇性阻塞，无法及时处理正常发送的请求，导致客户端发送的请求在缓冲区越积越多

怎么查询和服务端相连的每个客户端的输入缓冲区的使用情况呢？ 使用CLIENT LIST 命令：

CLIENT LIST
redis 127.0.0.1:6379> CLIENT LIST
addr=127.0.0.1:43143 fd=6 age=183 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
addr=127.0.0.1:43163 fd=5 age=35 idle=15 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
addr=127.0.0.1:43167 fd=7 age=24 idle=6 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get

CLIENT 命令返回的信息虽然很多，但我们只需要重点关注两类信息就可以了。

• 一类是和服务端相连的客户端的信息，比如addr
• 一类是与输入缓冲区相关的三个参数：
  • cmd：表示客户端最新执行的命令
  • qbuf：表示输入缓冲区已经使用的大小，表示cmd命令已经使用了xxx字节大小的缓冲区
  • qbuf-free：表示输入缓冲区尚未使用的大小，表示cmd命令还可以使用xxx字节大小的缓冲区
  • qbuf 和 qbuf-free 的总和就是，Redis 服务器端当前为已连接的这个客户端分配的缓冲区总大小。

怎么判断是不是异常呢？

• 如果qbuf很大，而qubf-free很小，就要注意了，因为这时候输入缓冲区已经占用了很多内存，而且没有什么空闲空间了。此时，客户端再写入大量命令的话，就会输入缓冲区溢出，redis的处理方法是把客户端连接关闭，结果就是业务程序无法进行数据存取了
• 通常情况下，redis服务器不止一个客户端，当多个客户端连接占用的内存总量超过了Redis 的 maxmemory 配置项时（例如 4GB），就会触发redis进行数据淘汰，一旦数据被淘汰出redis，再要访问这部分数据，就需要去后端数据库读取，这就降低了业务访问性能。
• 另外，如果使用多个客户端，导致redis内存占用过大，会导致内存溢出（out-of-memory）问题，进而会引起 Redis 崩溃

怎么避免输入缓冲区溢出呢？
（1）能不能通过参数把输入缓存大小调大呢？ Redis 的客户端输入缓冲区大小的上限阈值，在代码中就设定为了 1GB。也就是说，redis服务端允许为每个客户端最多暂存1GB的命令和数据。这是写死的
（2）因此，我们不能调大输入缓冲区的大小，所以要避免缓冲区溢出，就只能从数据命令的发送和处理速度入手。也就是避免客户端写入bigkey，以及避免redis主线程阻塞

如何应对输出缓冲区溢出

redis的输出缓冲区暂存的是redis主线程要返回给客户端的数据

• 一般来说，主线程返回给客户端的数据，既有简单且大小固定的 OK 响应（例如，执行 SET 命令）或报错信息，也有大小不固定的、包含具体数据的执行结果（例如，执行 HGET 命令）。
• 因此，redis为每个客户端设置的输出缓冲区也包括两部分：一部分，是一个大小为16KB的固定缓冲区空间，用来暂存OK响应和出错信息；另一部分，是一个可以动态增加的缓冲空间，用来暂存大小可变的响应结果。

那什么情况下会发生输出缓冲区溢出呢？
（1）服务器端返回 bigkey 的大量结果

（2）执行了MONITOR命令

• MONITOR 命令是用来监测 Redis 执行的。执行这个命令之后，就会持续输出监测到的各个命令操作，如下所示：

MONITOR
OK
1600617456.437129 [0 127.0.0.1:50487] "COMMAND"
1600617477.289667 [0 127.0.0.1:50487] "info" "memory"

• MONITOR 的输出结果会持续占用输出缓冲区，并越占越多，最后的结果就是发生溢出。所以，MONITOR 命令主要用在调试环境中，不要在线上生产环境中持续使用 MONITOR。

（3）缓冲区大小设置得不合理

• 和输入缓冲区不同，我们可以通过 clientoutput-buffer-limit 配置项，来设置缓冲区的大小。具体设置的内容包括两方面：
  • 设置缓冲区大小的上限阈值；
  • 设置输出缓冲区持续写入数据的数量上限阈值，和持续写入数据的时间的上限阈值。
• 在使用用 client-output-buffer-limit 来设置缓冲区大小的时候，我们需要先区分下客户端的类型。
  • 常规和redis服务器进行交互的普通客户端
  • 订阅了redis频道的客户端
  • 在redis主从集群中，主节点上也有一类客户端（从节点客户端）用来和从节点进行数据同步

（3.1） 当我们给普通客户端设置缓冲区大小时，通常可以在 Redis 配置文件中进行这样的设置：

/*
 * normal 表示当前设置的是普通客户端  是缓冲区大小限制 示缓冲区持续写入量限制  持续写入时间限制。
*/
client-output-buffer-limit normal 0 0 0

• 对于普通客户端来说，它每发送完一个请求，会等待请求结果返回后，再发送下一个请求，这种发送方式叫做阻塞式发送。在这种情况下，如果不是读取体量特别大的bigkey，服务端的输出缓冲区是不会被阻塞的
• 所以，我们通常把普通客户端的缓冲区大小限制，以及持续写入量限制、持续写入时间限制都设置为 0，也就是不做限制。

（3.2）对于订阅客户端来说，一般配置如下：

/*
* pubsub 参数表示当前是对订阅客户端进行设置
* 8mb 表示输出缓冲区的大小上限为 8MB，一旦实际占用的缓冲区大小要超过 8MB，服务器端就会直接关闭客户端的连接；
* 2mb 和 60 表示，如果连续 60 秒内对输出缓冲区的写入量超过 2MB 的话，服务器端也会关闭客户端连接。
*/
client-output-buffer-limit pubsub 8mb 2mb 60

• 一旦订阅的redis频道有消息了，服务端都会通过输出缓冲区把消息发送给客户端，所以，订阅客户端和服务器间的消息发送方式，不属于阻塞式发送。
• 不过，如果频道消息较多的话，也会占用较多的输出缓冲区空间。

综上，应对输出缓冲区溢出的方法：

• 避免 bigkey 操作返回大量数据结果
• 避免在线上环境中持续使用 MONITOR 命令
• 使用 client-output-buffer-limit 设置合理的缓冲区大小上限，或是缓冲区连续写入时间和写入量上限。

主从集群中的缓冲区

主从集群键的数据复制包括全量复制和增量复制两种。

• 全量复制是同步所有数据
• 增量复制只会把主从库网络端口期间主库收到的命令，同步给从库

无论是哪种形式的复制，为了保证主从接到的数据一致，都会用到缓冲区

复制缓冲区的溢出问题

• 在全量复制中，主节点在向从节点传输RDB文件的同时，会继续接收客户端发送的写命令请求。这些写命令就会先保存在复制缓冲区中，等RDB文件传输完成后，再发送给从节点去执行。主节点就会为每个从节点都维护一个复制缓冲区，来保证主从节点间的数据同步

• 所以，如果在全量复制时，从节点接收和加载RDB较慢，同属主节点接收到了大量的写命令，写命令在复制缓冲区中就会越积越多，最终导致溢出。复制缓冲区一旦发生溢出，主节点也会直接关闭和从节点进行复制操作的连接，导致全量复制失败。

那如何避免复制缓冲区溢出呢？

• 一方面，可以控制主节点保存的数据量大小。按通常的使用经验，我们会把主节点的数据量控制在 2~4GB，这样可以让全量同步执行得更快些，避免复制缓冲区累积过多命令。
• 另一方面，我们可以使用 client-output-buffer-limit 配置项，来设置合理的复制缓冲区大小。设置的依据，就是主节点的数据量大小、主节点的写负载压力和主节点本身的内存大小。
• 另外，主节点上复制缓存的内存开销，是每个从节点客户端输出缓冲区占用内存的总和。如果集群中从节点数量特别多的话，主节点的内存开销就会非常大。所以，我们还必须得控制和主节点连接的从节点个数，不要使用大规模的主从集群。

那到底应该怎么设置复制缓冲区大小呢？举个例子

• 在主节点执行如下命令：

/*
* slave 参数表明该配置项是针对复制缓冲区的。
* 512mb 代表将缓冲区大小的上限设置为 512MB；
* 128mb 和 60 代表的设置是，如果连续 60 秒内的写入量超过 128MB 的话，也会触发缓冲区溢出。
*/

config set client-output-buffer-limit slave 512mb 128mb 60

• 我们再继续看看这个设置对我们有啥用。假设一条写命令数据是 1KB，那么，复制缓冲区可以累积 512K 条（512MB/1KB = 512K）写命令。同时，主节点在全量复制期间，可以承受的写命令速率上限是 2000 条 /s（128MB/1KB/60 约等于 2000）。
• 这样一来，我们就得到了一种方法：在实际应用中设置复制缓冲区的大小时，可以根据写命令数据的大小和应用的实际负载情况（也就是写命令速率），来粗略估计缓冲区中会累积的写命令数据量；然后，再和所设置的复制缓冲区大小进行比较，判断设置的缓冲区大小是否足够支撑累积的写命令数据量。

复制积压缓冲区的溢出问题

增量复制时使用的缓冲区也称为复制积压缓冲区。

• 主节点在把接收到的写命令同步给从节点时，同时会把这些写命令写入复制积压缓冲区。
• 一旦从节点发生网络中断，再次和主节点恢复连接后，从节点就会从复制积压缓冲区中，读取断连期间主节点接收到的写命令，进而进行增量同步

• 复制积压缓冲区是一个大小有限的环形缓冲区。当主节点把复制积压缓冲区写满后，会覆盖缓冲区中的旧命令数据。如果从节点还没有同步这些旧命令数据，就会造成主从节点间重新开始执行全量复制。

怎么应对：方法是调整复制积压缓冲区的大小，也就是设置 repl_backlog_size 这个参数的值。

总结

按照缓冲区的用途，分为两类：

• 客户端的输入输出缓冲区
• 主从集群中主节点上的复制缓冲区和复制积压缓冲区

从缓冲区溢出对 Redis 的影响的角度，可以把这四个缓冲区分成两类：

• 缓冲区溢出导致网络连接关闭：普通客户端、订阅客户端、以及从节点客户端它们使用的缓冲区。本质上都是redis客户端和服务端之间，或者是主从节点之间为了传输命令数据而维护的。这些缓冲区一旦溢出，就会直接关闭连接。网络连接关闭造成的直接影响，就是业务数据无法读写redis，或者是主从节点全量同步失败，需要重新执行
• 缓冲区溢出导致命令数据丢失：主节点上的复制积压缓冲区属于环形缓冲区，一旦发生溢出，新写入的命令数据就会覆盖旧的命令数据，造成旧命令数据丢失，进而导致主从节点重新进行全量复制

从本质上看，缓冲区溢出，无非就是三个原因：命令数据发送过快过大；命令数据处理较慢；缓冲区空间过小。应对如下：

• 针对命令数据发送过快过大的问题，对于普通数据端来说，可以避免bigkey；对于复制缓冲区来说，就是避免过大的RDB文件
• 针对命令数据处理较慢的问题，解决方案就是减少redis主线程上的阻塞操作，比如使用异步的删除机制。
• 针对缓冲区空间过小的问题，解决方案就是使用 client-output-buffer-limit 配置项设置合理的输出缓冲区、复制缓冲区和复制积压缓冲区大小。ps：输入缓冲区的大小默认是固定的，我们无法通过配置来修改它，除非直接去修改 Redis 源码。