21如何使用21 Redis缓冲区简介：客户端输入输出缓冲区、如何应对输入缓冲区溢出、如何应对输出缓冲区溢出、主从集群中的缓冲区总结
前言缓冲区的功能是将命令数据临时存储在一个内存空间中，以避免因数据和命令的处理速度慢于发送速度而导致的数据丢失或性能问题。 但是，由于缓冲区内存有限，如果向内部写入数据的速度长于从内部读取数据的速度，则缓冲区需要越来越多的内存来临时存储数据。 如果缓冲区使用的内存超过了设置的上限阈值，将发生缓冲区溢出。
如果发生溢出，数据将会丢失。 随着数据的累积，如果缓冲区占用的内存量增加，并且Redis实例所在的计算机上的可用内存耗尽，Redis实例将崩溃。
缓冲区用于避免请求和数据丢失，必须正确使用，才能真正起到“避免”的作用。
Redis是典型的客户端-服务器体系结构，所有操作命令都必须在客户端发送到服务器端。 缓冲区在Redis中的主要应用场景：
客户端和服务器端之间通信时，用于临时保存客户端发送的命令数据或服务器端返回客户端的数据结果。 用于在主节点和从节点之间同步数据时临时存储主节点接收到的写命令和数据。 另一方面，客户端的输入/输出缓冲器为避免客户端和服务器端请求的发送和处理速度不一致，服务器端在每个连接的客户端上设置输入缓冲器和输出缓冲器，称为客户端输入缓冲器和输出缓冲器。
输入缓冲器首先临时保存客户端发送的命令，Redis主线程从输入缓冲器读取命令进行处理。 Redis主线程处理数据后，结果写入输出缓冲区，并通过输出缓冲区返回客户端，如下图所示。
二、应对输入缓冲器溢出的方法输入缓冲器是指临时存储客户端发送的请求命令，导致溢出的主要有以下两种：
在写入bigkey (例如，一次写入多个百万级聚合数据)的服务器端处理请求的速度太慢了。 例如，Redis主线程被间歇性阻止，无法立即处理常规请求，从而导致客户端发送的请求滞留在缓冲区中。 要查看连接到服务器端的每个客户端的输入缓冲区的使用情况，请使用客户端列表命令。
client listid=5addr=127.0.0.1336050487 FD=9name=age=4idle=0flags=ndb=0sub=0mu client命令返回的信息很多
连接到服务器端的客户端的信息。 情况显示了一个客户端的输入缓冲区情况，有多个客户端，输出结果的addr显示不同客户端的IP和端口号。 与输入缓冲区相关的三个参数： cmd表示客户端上次执行的命令。 在此示例中，正在运行客户端命令。 qbuf 指示输入缓冲区已经使用的大小。 此示例中的客户端命令已经使用了26字节的缓冲区。 qbuf-free。 指示输入缓冲区尚未使用的大小。 此示例中的客户端命令还提供32742字节的缓冲区。 qbuf和qbuf-free的总和是分配给Redis服务端当前连接的此客户端的缓冲区的总大小。 在本例中，总共分配了26 32742=32768字节，即32KB的缓冲区。 客户端列表命令通过输出结果来确定客户端输入缓冲区的内存消耗。 qbuf较大、qbuf-free较小时需要注意。 因为此时，输入缓冲区已经消耗了很多内存，没有可用空间。 此时，如果客户端写入更多命令，则客户端的输入缓冲区将溢出。 Redis的处理方法是关闭客户端连接。 其结果是，业务程序无法访问数据。
通常，Redis服务器端不仅服务一个客户端，而且在多个客户端连接占用的内存总量超过Redis的最大内存配置项(例如4GB )时，会触发Redis销毁数据。 当数据从Redis中丢弃时，必须访问后端数据库才能访问该数据，这会降低业务APP应用程序的访问性能。 更糟的是，使用多个客户端会增加Redis的内存消耗，引起内存溢出问题，引起Redis崩溃，严重影响业务APP应用程序
Redis的客户端输入缓冲区大小上限在代码中设置为1GB。 在Redis服务器端，每个客户端最多可以临时存储1GB的命令和数据。 1GB的大小适合一般的生产环境。 另一方面，该大小足以处理大多数客户端的请求。 另一方面，如果它再大，客户端可能会消耗过多的内存资源，导致Redis崩溃。
因此，Redis不提供用于调整客户端输入缓冲区大小的参数。 要避免输入缓冲区溢出，只能发送和处理数据命令的速度(如上所述，阻止客户端写入bigkey，以及阻止Redis主线程)。
三、输出缓冲器溢出的应对方法在Redis的输出缓冲器中，暂时存储有Redis主线程向客户端返回的数据。 主线程返回给客户端的数据包括简单且大小固定的OK响应(例如，运行SET命令)和错误消息，以及运行结果(例如，运行)，其中包括大小不固定的具体数据
HGET 命令）。Redis 为每个客户端设置的输出缓冲区也包括两部分：
一个大小为 16KB 的固定缓冲空间，用来暂存 OK 响应和出错信息；一个可以动态增加的缓冲空间，用来暂存大小可变的响应结果。发生输出缓冲区溢出的三种情况：
服务器端返回 bigkey 的大量结果；执行了 MONITOR 命令；缓冲区大小设置得不合理。bigkey 原本就会占用大量的内存空间，所以服务器端返回的结果包含 bigkey，必然会影响输出缓冲区。
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。如果在线上环境中偶尔使用 MONITOR 检查 Redis 的命令执行情况是没问题的。
输出缓冲区大小设置的问题和输入缓冲区不同，通过 client- output-buffer-limit 配置项来设置缓冲区的大小。设置的内容包括两方面：
设置缓冲区大小的上限阈值；设置输出缓冲区持续写入数据的数量上限阈值，和持续写入数据的时间的上限阈值。在具体使用 client-output-buffer-limit 来设置缓冲区大小的时候，需要先区分下客户端的类型。
两类客户端和 Redis 服务器端交互：
常规和 Redis 服务器端进行读写命令交互的普通客户端；订阅了 Redis 频道的订阅客户端。在 Redis 主从集群中，主节点上也有一类客户端（从节点客户端）用来和从节点进行数据同步。给普通客户端设置缓冲区大小时，在 Redis 配置文件中进行这样的设置：
client-output-buffer-limit normal 0 0 0normal 表示当前设置的是普通客户端，第 1 个 0 设置的是缓冲区大小限制，第 2 个 0 和第 3 个 0 分别表示缓冲区持续写入量限制和持续写入时间限制。
普通客户端每发送完一个请求，会等到请求结果返回后，再发送下一个请求，这种发送方式称为阻塞式发送。如果不是读取体量特别大的 bigkey， 服务器端的输出缓冲区一般不会被阻塞的。 所以通常把普通客户端的缓冲区大小限制，以及持续写入量限制、持续写入时间限 制都设置为 0，也就是不做限制。
订阅客户端一旦订阅的 Redis 频道有消息了，服务器端都会通过输出缓冲区把消息发给客户端。所以订阅客户端和服务器间的消息发送方式，不属于阻塞式发送。如果频道消息较多的话，也会占用较多的输出缓冲区空间。 因此给订阅客户端设置缓冲区大小限制、缓冲区持续写入量限制，以及持续写入时间限制，在 Redis 配置文件中设置：
client-output-buffer-limit pubsub 8mb 2mb 60pubsub 参数表示当前是对订阅客户端进行设置；8mb 表示输出缓冲区的大小上限为 8MB，一旦实际占用的缓冲区大小要超过 8MB，服务器端就会直接关闭客户端的连接；2mb 和 60 表示连续 60 秒内对输出缓冲区的写入量超过 2MB 的话，服务器端也会关闭客户端连接。
总结下如何应对输出缓冲区溢出：
避免 bigkey 操作返回大量数据结果；避免在线上环境中持续使用 MONITOR 命令。使用 client-output-buffer-limit 设置合理的缓冲区大小上限，或是缓冲区连续写入时 间和写入量上限。 四、主从集群中的缓冲区主从集群间的数据复制包括全量复制和增量复制两种。全量复制是同步所有数据，增量复制只会把主从库网络断连期间主库收到的命令同步给从库。无论在哪种形式的复制中，为了保证主从节点的数据一致，都会用到缓冲区。但是这两种复制场景下的缓冲区，在溢出影响和大小设置方面并不一样。
复制缓冲区的溢出问题
全量复制过程主节点在向从节点传输 RDB 文件的同时，会继续接收客户端发送的写命令请求。这些写命令就会先保存在复制缓冲区中，等 RDB 文件传输完成后，再发送给从节点去执行。主节点上会为每个从节点都维护一个复制缓冲区，来保证主从节点间的数据同步。
全量复制从节点接收和加载 RDB 较慢，同时主节点接收到了大量的写命令，写命令在复制缓冲区中就会越积越多，最终导致溢出。
主节点上的复制缓冲区，本质上也是一个用于和从节点连接的客户端（称之为从节点客户端），使用的输出缓冲区。复制缓冲区一旦发生溢出，主节点也会直接关闭和从节点进行复制操作的连接，导致全量复制失败。避免复制缓冲区发生溢出：
控制主节点保存的数据量大小。把主节点的数据量控制在 2~4GB，让全量同步执行得更快些，避免复制缓冲区累积过多命令。使用 client-output-buffer-limit 配置项，来设置合理的复制缓冲区大小。设置的依据是主节点的数据量大小、主节点的写负载压力和主节点本身的内存大小。在主节点执行如下命令： config set client-output-buffer-limit slave 512mb 128mb 60
slave 参数表明该配置项是针对复制缓冲区的。512mb 代表将缓冲区大小的上限设置为 512MB；128mb 和 60 代表的设置是，如果连续 60 秒内的写入量超过 128MB 的话，也会触发缓冲区溢出。
假设一条写命令数据是 1KB，复制缓冲区可以累积 512K 条（512MB/1KB = 512K）写命令。同时主节点在全量复制期间，可以承受的写命令速率上限是 2000 条 /s（128MB/1KB/60 约等于 2000）。
得到了一种方法：在实际应用中设置复制缓冲区的大小时，根据写命令数据的大小和应用的实际负载情况（也就是写命令速率），来粗略估计缓冲区中会累积的写命令数据量；然后再和所设置的复制缓冲区大小进行比较，判断设置的缓冲区大小是否足够支撑累积的写命令数据量。
复制缓冲区还会遇到一个问题：主节点上复制缓冲区的内存开销，会是每个从节点客户端输出缓冲区占用内存的总和。如果集群中的从节点数非常多的话，主节点的内存开销就会非常大。所以还必须得控制和主节点连接的从节点个数，不要使用大规模的主从集群。
总结：为了避免复制缓冲区累积过多命令造成溢出，引发全量复制失败，控制主节点保存的数据量大小，并设置合理的复制缓冲区大小。 同时需要控制从节点的数量，来避免主节点中复制缓冲区占用过多内存的问题。
复制积压缓冲区的溢出问题
增量复制使用的缓冲区称为复制积压缓冲区。 主节点在把接收到的写命令同步给从节点时，同时会把这些写命令写入复制积压缓冲区。 一旦从节点发生网络闪断，再次和主节点恢复连接后，从节点就会从复制积压缓冲区中， 读取断连期间主节点接收到的写命令，进而进行增量同步，如下图：
复制积压缓冲区的英文名字 repl_backlog_buffer。从缓冲区溢出的角度再来回顾下两个重点：复制积压缓冲区溢出的影响，以及如何应对复制积压缓冲区的溢出问题。
使用缓冲区以后，当命令数据的接收方处理速度跟不上发送方的发送速度时，缓冲区可以避免命令数据的丢失。
按照缓冲区的用途，例如是用于客户端通信还是用于主从节点复制，把缓冲区分成了客户端的输入和输出缓冲区，以及主从集群中主节点上的复制缓冲区和复制积压缓冲区。在排查问题的时候，可以快速找到方向：从客户端和服务器端的通信过程以及主从节点的复制过程中分析原因。
从缓冲区溢出对 Redis 的影响的角度，把这四个缓冲区分成两类做个总结：
缓冲区溢出导致网络连接关闭：普通客户端、订阅客户端，以及从节点客户端，它们使用的缓冲区，本质上都是 Redis 客户端和服务器端之间，或是主从节点之间为了传输命令数据而维护的。这些缓冲区一旦发生溢出，处理机制都是直接把客户端和服务器端的连接，或是主从节点间的连接关闭。网络连接关闭造成的直接影响，就是业务程序无法读写 Redis，或者是主从节点全量同步失败，需要重新执行。缓冲区溢出导致命令数据丢失：主节点上的复制积压缓冲区属于环形缓冲区，一旦发生溢出，新写入的命令数据就会覆盖旧的命令数据，导致旧命令数据的丢失，进而导致主从节点重新进行全量复制。缓冲区溢出的三个原因：
命令数据发送过快过大；命令数据处理较慢；缓冲区空间过小。缓冲区溢出的三个应对策略：
针对命令数据发送过快过大的问题，对于普通客户端来说可以避免 bigkey，而对于复制缓冲区来说，就是避免过大的 RDB 文件。针对命令数据处理较慢的问题，解决方案就是减少 Redis 主线程上的阻塞操作，例如使用异步的删除操作。针对缓冲区空间过小的问题，解决方案就是使用 client-output-buffer-limit 配置项设置合理的输出缓冲区、复制缓冲区和复制积压缓冲区大小。输入缓冲区的大小默认是固定的，无法通过配置来修改它，除非直接去修改 Redis 源码。