什么？你不知道 Redis 缓冲区会溢出？

说到缓冲区，在主从数据同步和增量复制的环节提到过，在这两个环节中缓冲区的主要作用是保存 Redis 的写操作，用来保证以免出现因为数据和命令的处理速度慢于发送速度而导致数据丢失和性能问题。

但是了缓冲区的内存空间也是有限制的，如果读速度慢于写速度，就会导致缓冲区不断的扩大内存来暂存数据。但缓冲区占用的内存超过了设定的上线阈值，就会出现缓冲区溢出导致数据丢失。一旦耗尽了 Redis 实例所在机器的可用内存，就会导致 Redis 实例崩溃，引发生产事故。

缓冲区应用场景

缓冲区的应用主要有两个应用场景：

1. 客户端和服务端之间通信。用来暂存客户端发送的命令数据，或是服务端返回给客户端的数据结果。
2. 主从节点数据同步。用来暂存主节点接收的写命令和数据。

普通客户端缓冲区

客户端输入和输出缓冲区

先来看一张图，这张图是客户端和服务端连接中，缓冲区的说明。

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

可能导致溢出的情况

输入缓冲区可能导致溢出的情况：

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

就先来看看如何查看输入缓冲区的内存使用情况吧，了解哪个客户端引起的：

# Redis 提供的查看客户端连接信息的命令
CLIENT LIST
id=5 addr=127.0.0.1:50487 fd=9 name= age=4 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client

CLIENT 命令返回的信息可以划分为两类：

1. 一类是与服务器端连接的客户端信息。如 addr。

2. 一类是与输入缓冲区相关的三个参数：

   1. cmd：表示客户端最新执行的命令。示例是 CLIENT 命令。
   2. qbuf：表示输入缓冲区已经使用的大小。示例是 CLIENT 命令已经使用了 26 字节大小的缓冲区。
   3. qbuf-free：表示输入缓冲器尚未使用的大小。示例 CLIENT 命令还可以使用 32742 字节的缓冲区。

qbuf 和 qbuf-free 的总和就是，Redis 服务器端当前为已连接的客户端分配的缓冲区总大小。示例总共分配了 26 + 32742 = 32768 字节（32KB）。

溢出产生的影响

输入缓冲区溢出产生的影响：

1. 如果 qubf-free 耗尽，就会引起客户端输入缓冲区溢出，Redis 的处理方法就是把客户端连接关闭，导致的结果就是业务程序无法进行数据存取。
2. 通常情况下，会有很多的客户端连接，当客户端连接占用的内存总量，超过了 Redis 的 maxmemory 配置时，就会触发 Redis 进行数据淘汰，影响业务程序的访问性能。甚至多个客户端会导致 Redis 内存占用过大，也会导致内存溢出问题，进而引起 Redis 崩溃。

怎么避免？

可以从两个角度着手考虑：

1. 把缓冲区调大。输入缓冲区大小的上限阈值，在代码中就限定为 1GB，无法通过参数调节，对于一般情况是已经合适了。
2. 从数据命令的发送和处理速度入手。就是尽量避免客户端写入 bigkey，以及避免 Redis 主线程阻塞。

输出缓冲区溢出

Redis 输出缓冲区暂存的是 Redis 主线程要返回给客户端的数据。主线程返回给客户端的数据，既有简单且大小固定的 OK 响应或报错信息，也有大小不固定、包含具体数据的执行结果。

Redis 为每个客户端输出缓冲区划分了两部分：

1. 一个大小为 16KB 的固定缓冲空间，用来暂存 OK 响应和出错信息。
2. 一个可以动态增加的缓冲空间，用来暂存大小可变的响应结果。

可能导致溢出的情况

1. 服务器端返回 bigkey 的大量结果。
2. 执行了 MONITOR 命令。
3. 缓冲区大小设置不合理。

MONNITOR 命令是用来检测 Redis 执行的，这个命令会持续输出检测到的各个命令操作：

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

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

输出缓冲区大小是可以通过 client-output-buffer-limit 配置配置的，具体包含量方面内容：

1. 设置缓冲区大小的上限阈值。
2. 设置输出缓冲区持续写入数据的数量上限阈值，和持续写入数据的时间上限阈值。

应对方式

针对三种可能情况总结下应对方式：

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

主从集群中的缓冲区

主从集群间数据复制包括全量复制和增量复制两种，无论那种形式的复制，为了保证主从节点的数据一致，都会用到缓冲区，但是这两种场景下的缓冲区，在溢出影响和大小设置方面并不一样。

复制缓冲区（replication buffer）溢出问题

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

如果在全量复制时，从节点接收和加载 RDB 较慢，写命令就会在复制缓冲区越积越多，最终导致溢出。溢出后主节点会直接关闭和从节点的连接，导致全量复制失败。

怎么避免？

提供以下三点建议来避免：

1. 控制主节点的数据量大小，尽量控制在 2-4GB，可以让全量同步执行的快些。
2. 通过 client-output-buffer-limit 配置项，合理设置复制缓冲区大小。设置依据就是主节点的数据量大小、主节点的写负载压力和主节点本身的内存大小。
3. 控制从节点数量，不要使用大规模的主从集群，避免多数从节点同时进行全量同步。

复制积压缓冲区（repl_backlog_buffer）溢出问题

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

优化建议

1. 通过配置项 repl_backlog_size 调整复制积压缓冲区大小。

repl_backlog_size

同时再说下 repl_backlog_size 计算依据：

复制积压缓冲区空间大小 = 主库写入命令速度 数据大小 - 主从库间网络传输速度 数据大小；

repl_backlog_size = 复制积压缓冲区空间大小 * 2；

举例：

如果主库每秒写入 2000 个数据，每个数据大小为 2KB，主从库间网络传输 1000 个/秒。那么，有 1000 个数据需要缓冲起来，至少需要 2MB 的缓冲空间，按照 2 倍的量就是 4MB；

client-output-buffer-limit 说明

client-output-buffer-limit 设置缓冲区时，是可以区分客户端的类型的。

客户端分类

和 Redis 实例进行交互的客户端主要划分为两类：

1. 常规的和 Redis 服务器端交互的普通客户端，以及订阅了 Redis 频道的订阅客户端。
2. 主从集群中从节点客户端。

示例

# 给普通客户端设置缓冲区大小示例：
client-output-buffer-limit normal 0 0 0

normal 表示当前设置的是普通客户端

第 1 个 0 表示设置的是缓冲区大小限制

第 2 个 0 表示缓冲区持续写入量限制

第 3 个 0 表示缓冲区持续写入时间限制

# 给订阅客户端设置
client-output-buffer-limit pubsub 8mb 2mb 60

8mb 表示缓冲区大小上限为 8mb，超过就断开客户端连接

2mb 表示缓冲区持续写入量限制为 2mb

60 表示缓冲区持续写入时间限制为 60 秒

达到连续条件也会断开客户端连接

# 给从节点客户端设置
client-output-buffer-limit slave 512mb 128mb 60

以从节点客户端设置为例，计算下写入负载：

假如一条写命令数据是 1KB，复制缓冲区可以累积 512K 条（512MB/1KB = 512K）写命令，主节点在全量复制期间，可以承受的写命令速率上限是 2000条/秒（128MB/1KB/60 约等于 2000）；