Redis核心技术17-缓冲区

缓冲区主要就是用一块内存空间来暂时存放命令数据，以免出现因为数据和命令的处理速度慢于发送速度而导致数据丢失和性能问题。

但缓冲区也类似一个水杯，内存空间是有限的，如果往里面倒水速度（写入数据的速度）大于流水速度（取数据的速度），就会导致缓冲区内存超出设定的上限阈值时，就会出现缓冲区溢出。而缓冲区溢出也就意味着丢失数据。

关于缓冲区在Redis的主要应用场景有两个：

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

客户端输入和输出缓冲区

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

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

应对输入缓冲区溢出

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

• 写入了bigkey，写入了一个大的集合类型数据
• 倒水速度太慢（服务端处理请求的速度过慢），如果Redis出现间隙性阻塞，无法及时处理正常发送的请求，导致客户端发送的请求在缓冲区越积越多。

对于缓冲区溢出，我们需要从如何查看缓冲区内存使用情况和如何避免溢出这两个问题出发。

查看缓冲区内存使用情况

> CLIENT LIST
id=2 addr=127.0.0.1:56395 fd=7 name= age=7 idle=7 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=info
id=3 addr=127.0.0.1:56424 fd=8 name= age=2 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

相关参数如下：

• cmd，表示客户端最新执行的命令。
• qbuf，表示输入缓冲区已经使用的大小
• qbuf-free，表示输入缓冲区尚未使用的大小

如果 qbuf 很大，而同时 qbuf-free 很小，就要引起注意了，因为这时候输入缓冲区已经占用了很多内存，而且没有什么空闲空间了。此时，客户端再写入大量命令的话，就会引起客户端输入缓冲区溢出，Redis 的处理办法就是把客户端连接关闭，结果就是业务程序无法进行数据存取了。

避免溢出

Redis并没有提供参数来调节客户端缓冲区的大小，如果要避免输入缓冲区溢出，只能从数据命令的发送和处理速度入手。也就是避免客户端写入bigkey，以及避免Redis主线程阻塞。

应对输出缓冲区溢出

首先Redis的输出缓冲区暂存的是Redis主线程要返回给客户端的数据，这些数据主要分为两类：

• 简单且大小固定的 OK 响应（例如，执行 SET 命令）或报错信息
• 大小不固定的、包含具体数据的执行结果（例如，执行 HGET 命令）。

所以，Redis为每个客户端设置的输出缓冲区也包含两个部分：

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

而输出缓冲区发送溢出的情况主要有三种：

• 服务器端返回 bigkey 的大量结果
• 执行了 MONITOR 命令
• 缓冲区大小设置得不合理

bigkey

bigkey本来就会占用大量的内存空间，所以服务端返回的结果包含bigkey，必然会影响输出缓冲区。

MONITOR

MONITOR 命令是用来监测 Redis 执行的。执行这个命令之后，就会持续输出监测到的各个命令操作，但是MONITOR 的输出结果会持续占用输出缓冲区，并越占越多，最后的结果就是发生溢出，因此MONITOR 命令主要用在调试环境中，不要在线上生产环境中持续使用 MONITOR。

缓冲区大小设置

我们可以通过client-output-buffer-limit 配置项，来设置缓冲区的大小。具体设置的内容包括两方面：

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

对于和Redis实例进行交互的应用程序来说，主要使用两类客户端和 Redis 服务器端交互，分别是常规和 Redis 服务器端进行读写命令交互的普通客户端，以及订阅了 Redis 频道的订阅客户端。

普通客户端

client-output-buffer-limit normal 0 0 0

其中，normal 表示当前设置的是普通客户端，第 1 个 0 设置的是缓冲区大小限制，第 2 个 0 和第 3 个 0 分别表示缓冲区持续写入量限制和持续写入时间限制。

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

订阅客户端

client-output-buffer-limit pubsub 8mb 2mb 60

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

应对输出缓冲区溢出总结

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

主从集群的缓冲区

主从集群间的数据复制包括全量复制和增量复制两种。全量复制是同步所有数据，而增量复制只会把主从库网络断连期间主库收到的命令，同步给从库。两种方式为了保证主从节点的数据一致，都会用到缓冲区。

复制缓冲区的溢出问题

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

所以，如果在全量复制时，从节点接收和加载 RDB 较慢，同时主节点接收到了大量的写命令，写命令在复制缓冲区中就会越积越多，最终导致溢出。

复制缓冲区一旦发生溢出，主节点也会直接关闭和从节点进行复制操作的连接，导致全量复制失败。那么如何避免复制缓冲区发生溢出呢？

• 可以控制主节点保存的数据量大小。按通常的使用经验，我们会把主节点的数据量控制在 2~4GB，这样可以让全量同步执行得更快些，避免复制缓冲区累积过多命令。
• 我们可以使用 client-output-buffer-limit 配置项，来设置合理的复制缓冲区大小。设置的依据，就是主节点的数据量大小、主节点的写负载压力和主节点本身的内存大小。
• 控制和主节点连接的从节点个数，不要使用大规模的主从集群。

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

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

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

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

其次，为了应对复制积压缓冲区的溢出问题，我们可以调整复制积压缓冲区的大小，也就是设置 repl_backlog_size 这个参数的值

参考

Redis核心技术与实战 (opens new window)