20 | 删除数据后，为什么内存占用率还是很高？

1、前言

这样一个问题：明明做了数据删除，数据量已经不大了，为什么使用 top 命令查看时，还会发现 Redis 占用了很多内存呢？

因为当数据删除后，Redis 释放的内存空间会由内存分配器管理，并不会立即返回给操作系统。所以，操作系统仍然会记录着给 Redis 分配了大量内存。

一个潜在的风险点：Redis 释放的内存空间可能并不是连续的，这些不连续的内存空间很有可能处于一种闲置的状态。

导致一个问题：虽然有空闲空间，Redis 却无法用来保存数据，不仅会减少 Redis 能够实际保存的数据量，还会降低 Redis 运行机器的成本回报率。

类似的可以把 Redis 的内存空间比作高铁上的车厢座位数。如果高铁的车厢座位数很多，但运送的乘客数很少，那么，高铁运行一次的效率低，成本高，性价比就会降低，Redis 也是一样

2、什么是内存碎片？

通常情况下，内存空间闲置，往往是因为操作系统发生了较为严重的内存碎片。

首先了解什么是内存碎片。

车厢座位碎片

操作系统的内存碎片：虽然操作系统的剩余内存空间总量足够，但是，应用申请的是一块连续地址空间的 N 字节，但在剩余的内存空间中，没有大小为 N 字节的连续空间，那么，这些剩余空间就是内存碎片（比如上图中的“空闲 2 字节”和“空闲 1 字节”，就是这样的碎片）。

3、内存碎片是如何形成的？

两个原因：

1）、内因：操作系统内存分配机制。

内因：内存分配器的分配策略--决定了操作系统无法做到“按需分配”。

内存分配器一般是按固定大小来分配内存，而不是完全按照应用程序申请的内存空间大小给程序分配。

Redis 可以使用 libc、jemalloc、tcmalloc 多种内存分配器来分配内存，默认使用 jemalloc。

jemalloc 的分配策略之一，是按照一系列固定的大小划分内存空间，例如 8 字节、16 字节、32 字节、48 字节，…, 2KB、4KB、8KB 等。当程序申请的内存最接近某个固定值时，jemalloc 会给它分配相应大小的空间。本身就会产生一定的碎片。

申请 6 字节，jemalloc 按分配策略分配 8 字节

这样分配的好处是为了减少分配次数，假设申请20K，那么会给他分配32，如果在需要10，就不用再次向操作系统申请分配了，节省了一次分配。

但是，如果 Redis 每次向分配器申请的内存空间大小不一样，这种分配方式就会有形成碎片的风险，而这正好来源于 Redis 的外因了。

2）、外因：Redis 负载特称。

外因：键值对大小不一样和删改操作

第一个外因:Redis中键值对大小不一致，申请内存空间分配时，本身就会有大小不一的空间需求

第二个外因:这些键值对会被修改和删除，这会导致空间的扩容和释放。

一方面，如果修改后的键值对变大或变小了，就需要占用额外的空间或者释放不用的空间。

另一方面，删除的键值对就不再需要内存空间了，此时，就会把空间释放出来，形成空闲空间。

空间碎片详解

一开始，应用 A、B、C、D 分别保存了 3、1、2、4 字节的数据，并占据了相应的内存空间。然后，应用 D 删除了 1 个字节，这个 1 字节的内存空间就空出来了。紧接着，应用 A修改了数据，从 3 字节变成了 4 字节。为了保持 A 数据的空间连续性，操作系统就需要把 B 的数据拷贝到别的空间，比如拷贝到 D 刚刚释放的空间中。此时，应用 C 和 D 也分别删除了 2 字节和 1 字节的数据，整个内存空间上就分别出现了 2 字节和 1 字节的空闲碎片。如果应用 E 想要一个 3 字节的连续空间，显然是不能得到满足的。因为，虽然空间总量够，但却是碎片空间，并不是连续的。

大量内存碎片的存在，会造成 Redis 的内存实际利用率变低。

4、如何判断是否有内存碎片？

INFO memory 命令查看内存的使用情况

INFO memory

# Memory

used_memory:1073741736

used_memory_human:1024.00M

used_memory_rss:1997159792

used_memory_rss_human:1.86G

…

mem_fragmentation_ratio:1.86

mem_fragmentation_ratio 的指标：表示的就是 Redis 当前的内存碎片率。

mem_fragmentation_ratio 大于 1 但小于 1.5。这种情况是合理的。

mem_fragmentation_ratio 大于 1.5 。这表明内存碎片率已经超过了 50%。

mem_fragmentation_ratio = used_memory_rss/ used_memory

used_memory_rss 是操作系统实际分配给 Redis 的物理内存空间，里面就包含了碎片；而 used_memory 是 Redis 为了保存数据实际申请使用的空间。

5、如何清理内存碎片？

1）、“简单粗暴”的方法就是重启 Redis 实例

带来两个后果：1）、没持久化的数据丢失；2）、恢复阶段时常取决于aof、rdb文件大小，如果只有一个redis实例，那么恢复阶段无法提供服务。

2）、优雅的方式：Redis 4.0 提供的 activedefrag ，启用自动内存碎片清理 

#将 activedefrag  设置成yes，这个命令只是启用了自动清理功能

config set activedefrag yes 

什么时候自动清理？

受到下面这两个参数的控制。这两个参数分别设置了触发内存清理的一个条件，如果同时满足这两个条件，就开始清理。在清理的过程中，只要有一个条件不满足了，就停止自动清理。

active-defrag-ignore-bytes 100mb：表示内存碎片的字节数达到 100MB 时，开始清理；

active-defrag-threshold-lower 10：表示内存碎片空间占操作系统分配给 Redis 的总空间比例达到 10% 时，开始清理。

除了这两个参数，还提供了两个参数监控CPU的占用时间，既保证正常清理工作，又避免了降低Redis性能。

active-defrag-cycle-min 25： 表示自动清理过程所用 CPU 时间的比例不低于25%，保证清理能正常开展；

active-defrag-cycle-max 75：表示自动清理过程所用 CPU 时间的比例不高于75%，一旦超过，就停止清理，从而避免在清理时，大量的内存拷贝阻塞 Redis，导致响应延迟升高。

自动内存碎片清理机制在控制碎片清理启停的时机上，既考虑了碎片的空间占比、对 Redis 内存使用效率的影响，还考虑了清理机制本身的 CPU 时间占比、对 Redis 性能的影响。

3）、自动清理原理

内存碎片清理，简单来说，就是“搬家让位，合并空间”。

当有数据把一块连续的内存空间分割成好几块不连续的空间时，操作系统就会把数据拷贝到别处。此时，数据拷贝需要能把这些数据原来占用的空间都空出来，把原本不连续的内存空间变成连续的空间。否则，如果数据拷贝后，并没有形成连续的内存空间，这就不能算是清理了。

自动清理原理

不过需要注意：清理是有代价的，操作系统拷贝数据后再释放原空间会带来开销，会影响Redis性能。(因为 Redis 是单线程，在数据拷贝时，Redis 只能等着，这就导致 Redis 无法及时处理请求，性能就会降低)

解决：Redis 专门为自动内存碎片清理功机制设置的参数。可以通过设置参数，来控制碎片清理的开始和结束时机，以及占用的 CPU 比例，从而减少碎片清理对 Redis 本身请求处理的性能影响。（具体看上面）

6、小节

Redis 的内存空间效率问题，这里面的一个关键技术点就是要识别和处理内存碎片。简单来说，就是“三个一”：

INFO memory 命令是一个好工具，可以帮助你查看碎片率的情况；

碎片率阈值是一个好经验，可以帮忙你有效地判断是否要进行碎片清；

内存碎片自动清理是一个好方法，可以避免因为碎片导致 Redis 的内存实际利用率降低，提升成本收益率。

小贴士：内存碎片自动清理涉及内存拷贝，这对 Redis 而言，是个潜在的风险。如果在实践过程中遇到 Redis 性能变慢，记得通过日志看下是否正在进行碎片清理。如果 Redis 的确正在清理碎片，那么，建议调小 active-defrag-cycle-max 的值，以减轻对正常请求处理的影响。（也就是第四个监控CPU时间的参数）

---

21 | 缓冲区：一个可能引发“惨案”的地方

1、前言

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

缓冲区超出了设置的阈值，会发生缓冲区溢出，就会丢数据。如果不给缓冲区设置上限，那么缓冲区越来越大，一旦耗空Redis实例所在机器可用内存，会导致Redis挂掉。

缓冲区两个场景：

1）、客户端与服务器通信时，用来暂存客户端发送的命令数据，或者是服务器端返回给客户端的数据结果

2）、在主从节点间进行数据同步时，用来暂存主节点接收的写命令和数据。

2、客户端输入和输出缓冲区

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

客户端输入缓冲区和输出缓冲区

3、如何应对输入缓冲区溢出？

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

1）、写入了 bigkey，比如一下子写入了多个百万级别的集合类型数据；

2）、服务器端处理请求的速度过慢，例如，Redis 主线程出现了间歇性阻塞，无法及时处理正常发送的请求，导致客户端发送的请求在缓冲区越积越多。

从如何查看输入缓冲区的内存使用情况，以及如何避免溢出，使用 CLIENT LIST 命令：

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 mu

关注两类信息：

1）、服务器端连接的客户端的信息

这个案例展示的是一个客户端的输入缓冲区情况，如果有多个客户端，输出结果中的 addr 会显示不同客户端的 IP 和端口号。

2）、与输入缓冲区相关的三个参数：

cmd，表示客户端最新执行的命令。

qbuf，表示输入缓冲区已经使用的大小。

qbuf-free，表示输入缓冲区尚未使用的大小。

总结：如何避免？-------一是把缓冲区调大，二是从数据命令的发送和处理速度入手。

没有办法通过参数调整输入缓冲区的大小， Redis 的客户端输入缓冲区大小的上限阈值，在代码中就设定为了 1GB，（Redis服务器端允许为每个客户端最多暂存 1GB 的命令和数据。）如果再大，可能会占用过多的内存资源。

其次从数据命令的发送和处理速度入手，也就是前面提到的避免客户端写入 bigkey，以及避免 Redis 主线程阻塞。

4、如何应对输出缓冲区溢出？

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

有OK、报错信息、不固定大小的数据信息结果等。

因此，Redis 为每个客户端设置的输出缓冲区也包括两部分：

一部分，是一个大小为 16KB的固定缓冲空间，用来暂存 OK 响应和出错信息；

另一部分，是一个可以动态增加的缓冲空间，用来暂存大小可变的响应结果。

5、什么情况下会发生输出缓冲区溢出呢？

1）、服务器端返回 bigkey 的大量结果；----占用大量内存

2）、执行了 MONITOR 命令；

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

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

MONITOR

OK

1600617456.437129 [0 127.0.0.1:50487] "COMMAND"

1600617477.289667 [0 127.0.0.1:50487] "info" "memory"

MONITOR 的输出结果会持续占用输出缓冲区，并越占越多，最后的结果就是发生溢出。

输出缓冲区大小设置的问题。和输入缓冲区不同，我们可以通过 clientoutput-buffer-limit 配置项，来设置缓冲区的大小。具体设置的内容包括两方面：

1）、设置缓冲区大小的上限阈值；

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

两类客户端和 Redis 服务器端交互，分别是常规和 Redis 服务器端进行读写命令交互的普通客户端，以及订阅了 Redis 频道的订阅客户端。

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

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

client-output-buffer-limit normal 0 0 0

对于订阅了 Redis 频道的订阅客户端，这么设置：

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

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

订阅客户端和服务器间的消息发送方式，不属于阻塞式发送。不过，如果频道消息较多的话，也会占用较多的输出缓冲区空间。

总结：如何避免输出缓冲区溢出？

避免 bigkey 操作返回大量数据结果；

避免在线上环境中持续使用 MONITOR 命令。

使用 client-output-buffer-limit 设置合理的缓冲区大小上限，或是缓冲区连续写入时间和写入量上限。

6、主从集群中的缓冲区

主从集群间的数据复制包括全量复制和增量复制两种。全量复制是同步所有数据，而增量复制只会把主从库网络断连期间主库收到的命令，同步给从库。

无论在哪种形式的复制中，为了保证主从节点的数据一致，都会用到缓冲区。

7、复制缓冲区的溢出问题---复制缓冲区

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

全量复制缓冲区

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

主节点上的复制缓冲区，本质上也是一个用于和从节点连接的客户端（我们称之为从节点客户端），使用的输出缓冲区。复制缓冲区一旦发生溢出，主节点也会直接关闭和从节点进行复制操作的连接，导致全量复制失败。

如何避免？两方面

1）、控制主节点保存的数据量大小。可以控制主节点数据量在2-4GB，这样可以让全量同步执行得更快些，避免复制缓冲区累积过多命令。

2）、使用 client-output-buffer-limit 命令配置项，控制复制缓冲区大小。就是主节点的数据量大小、主节点的写负载压力和主节点本身的内存大小。

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

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

总结一下：

为了避免复制缓冲区累积过多命令造成溢出，引发全量复制失败，我们可以控制主节点保存的数据量大小，并设置合理的复制缓冲区大小。同时，我们需要控制从节点的数量，来避免主节点中复制缓冲区占用过多内存的问题。

8、复制积压缓冲区的溢出问题---积压缓冲区 repl_backlog_buffer

增量复制时使用

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

增量复制的积压缓冲区

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

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

哈哈，我没记错，是二倍关系 repl_backlog_size = 缓冲空间大小 * 2

9、小结

1）、Redis 中使用的缓冲区。使用缓冲区以后，当命令数据的接收方处理速度跟不上发送方的发送速度时，缓冲区可以避免命令数据的丢失。

2）、按照缓冲区的用途，例如是用于客户端通信还是用于主从节点复制，把缓冲区分成了客户端的输入和输出缓冲区，以及主从集群中主节点上的复制缓冲区和复制积压缓冲区。

3）、缓冲区溢出对 Redis 的影响的角度，再把这四个缓冲区分成两类做个总结：

缓冲区溢出导致网络连接关闭：普通客户端、订阅客户端，以及从节点客户端，它们使用的缓冲区，本质上都是 Redis 客户端和服务器端之间，或是主从节点之间为了传输命令数据而维护的。这些缓冲区一旦发生溢出，处理机制都是直接把客户端和服务器端的连接，或是主从节点间的连接关闭。网络连接关闭造成的直接影响，就是业务程序无法读写 Redis，或者是主从节点全量同步失败，需要重新执行。

缓冲区溢出导致命令数据丢失：主节点上的复制积压缓冲区属于环形缓冲区，一旦发生溢出，新写入的命令数据就会覆盖旧的命令数据，导致旧命令数据的丢失，进而导致主从节点重新进行全量复制。

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

5）、应对策略

a、针对命令数据发送过快过大的问题，对于普通客户端来说可以避免 bigkey，而对于复制缓冲区来说，就是避免过大的 RDB 文件。

b、针对命令数据处理较慢的问题，解决方案就是减少 Redis 主线程上的阻塞操作，例如使用异步的删除操作。

c、针对缓冲区空间过小的问题，解决方案就是使用 client-output-buffer-limit 配置项设置合理的输出缓冲区、复制缓冲区和复制积压缓冲区大小。当然，不要忘了，输入缓冲区的大小默认是固定的，我们无法通过配置来修改它，除非直接去修改 Redis 源码。