Redis数据已经删除了，为什么内存占用还是很高？
Redis做了数据删除操作，为什么使用top命令时，还是显示Redis占了很多内存？
没做相关功课的人觉得这个问题有问题，删了数据还说占着内存，面试官不是在误导我吗，事实并非如此！
这里先说答案 📝📝
🌐 实际上，这是因为，当数据删除后，Redis 释放的内存空间会由内存分配器管理，并不会立即返回给操作系统。所以，操作系统仍然会记录着给 Redis 分配了大量内存。
而 used_memory_rss 记录着在操作系统角度，Redis进程占用的物理总内存
这样看来文章好像讲完了，开头就知道答案，当然不是，内容多着呢~
文章将从下面这些点分析扩展你对于Redis内存方面的知识点，以及内存碎片和如何清理内存碎片。
Redis内存消耗组成
Redis内存消耗主要在于其主进程消耗和子进程消耗。而主进程消耗又主要包括自身内存、对象内存、缓冲区内存、内存碎片四个方面：
自身进程占用内存
Redis进程自身所占用的内存，这部分内存通常很小，一个空的Redis进程所消耗的内存几乎可以忽略不计
数据对象内存
对象占用的内存是Redis中占用内存最大的，这里存储这我们的键值对，我们知道不同的数据类型占用的内存空间大小也不同，特别是那种大key占用内存的情况就更惊人了。
缓冲区
Redis主要有三大缓冲区：客户端缓冲区、AOF缓冲区、复制缓存区
📔 客户端缓冲区： 为了解决客户端和服务端请求和处理速度不匹配问题(即CPU 与 I/O 设备速度不匹配的矛盾)，分为输入和输出缓冲区。
输入缓冲区会先把客户端发送过来的命令暂存起来，Redis 主线程再从输入缓冲区中读取命令，进行处理。当在处理完数据后，会把结果写入到输出缓冲区，再通过输出缓冲区返回给客户端。
📘 AOF缓冲区： 在进行AOF持久化时所用到的缓冲区，AOF缓冲区消耗的内存取决于AOF重写时间和写入命令量， 分为AOF缓冲区和AOF重写缓冲区
📙 复制缓冲区：是在集群环境中为了保证主从节点数据同步的所设置的，由于主从节点间的数据复制包括全量复制和增量复制两种。因此复制缓冲区也分为复制缓冲区和复制积压缓冲区两种，分别用于全量和增量同步
内存碎片
内存碎片主要是有两个原因：操作系统的内存分配机制、Redis存储特性，这两个原因我们在文章中会具体提到。
子进程消耗
子进程消耗是指在RDB、AOF重写时fork()子进程的内存消耗
有人说这不是用到了写时复制技术吗？
📢 虽然子进程可以不用完全复制父进程的物理内存，但是仍然需要复制其内存页表，在此期间如果有写入操作则需要复制出一份副本出来，因此同样会消耗一部分内存，消耗的内存两取决于RDB和AOF重写期间的写入命令数量。
查看内存指标
查看当前Redis相关内存信息用 info memory 命令，如果是集群使用 cluster info命令
127.0.0.1:6379> info memory
# Memory
used_memory:856472 // Redis 存储数据占用的内存量
used_memory_human:836.40K // 人类可读形式返回内存总量
used_memory_rss:1282048 // 操作系统角度，进程占用的物理总内存
used_memory_rss_human:1.22M // used_memory_rss 可读性模式展示
used_memory_peak:857448 // 内存使用的最大值，表示 used_memory 的峰值
used_memory_peak_human:837.35K // 以可读的格式返回 used_memory_peak的值
used_memory_lua:37888 // Lua 引擎所消耗的内存大小。
used_memory_lua_human:37.00K
maxmemory:2147483648 // 能使用的最大内存值，字节为单位。
maxmemory_human:2.00G // 可读形式
maxmemory_policy:noeviction // 内存淘汰策略
// used_memory_rss / used_memory 的比值，代表内存碎片率
mem_fragmentation_ratio:2.79
used_memory_rss：操作系统分配给 Redis 进程的内存空间（包含内存碎片占用的空间），此数据结果约等于top、ps命令看到的数据结果，是从操作系统层看到的数据
maxmemory：Redis 最大可用内存，0表示不限制，我们一般会设置这个值，避免所有内存超过物理内存
内存为何没释放
Redis 释放的内存空间会由内存分配器管理，并不会立即返回给操作系统，是因为采用了一种称为“惰性删除”的机制，即在数据被删除之后，并不会立即释放内存空间，而是等到有新数据需要使用该空间时才会释放。
这种方式的好处是可以减少内存分配和释放的开销，提高 Redis 的性能。
但是Redis释放内存空间可能不是连续的，**可能导致空间闲置(也就是出现内存碎片)，**而内存碎片过大会导致明明有空间可用，但是却无法存储数据！
ok！我们继续看看什么是内存碎片
内存碎片
前面我们已经了解了Redis占用内存的组成以及如何查看内存占用信息，接下来看什么是内存碎片和导致出现内存碎片的原因。
Redis使用多种内存分配策略，例如 jemalloc 和 libc，这些分配器无法做到按需分配，通常会按照固定大小进行分配。例如，如果Redis申请6字节的内存，操作系统会分配8字节的内存给Redis使用，剩下的2个字节空间无法被使用就是内存碎片。
但这种分配方式也有优势，可以减少向操作系统申请空间分配。
导致Redis产生内存碎片主要由以下两点：
• 内存分配机制导致
• 数据修改引发空间扩容和释放
内存分配机制导致
操作系统的架构和 Redis jemalloc 分配策略无法做到按需分配，而是应用程序申请内存大小必须是一块连续的内存地址空间。
这种连续是按固定大小来分配的，比如：8字节、16 字节、32 字节、64 字节 … 这种方式会在程序申请内存接近某个值的时候，jemalloc就会给它分配响应大小的内存空间。
上图中：
第一次存储数据是需要6字节，而Redis内存分配策略给你分配了8字节，空出2个字节的空间。
第二次存储数据是需要4个字节，但是空出的2个字节无法保存4字节数据，所以会再次向系统申请8字节内存空间，空出了4字节，两次存储数据就多出来6个字节的内存碎片。
这也就是内存分配机制导致的形成碎片的风险和原因。
数据修改引发空间扩容和释放
这个原因应该更好理解吧，若修改数据时占用的空间有变化，此时就需要扩容或者缩容；而删除数据也会将内存释放出来，形成碎片。
• 各数据占用内存字节空间分别是A：2、B：1、C：3、D：3
• 此时D释放了一个字节空间
• A修改了数据，增加了一个字节。为保证A的内存空间连续性，B的数据拷贝到了第二阶段D释放出来的那个字节位置
• C修改后删除了2个字节空间
可以看出经过一系列对数据的修改，C和D之间有2字段内存空间，此时多出来2字节空间就是内存碎片。
处理内存碎片
如何在进行处理内存碎片，那么以什么为参考呢？
前面说的 info memory命令，如果指标值 mem_fragmentation_ratio (内存碎片率)的值，在 1 < 碎片率 < 1.5，可以认为是合理的，而大于 1.5 说明碎片已经超过 50%，我们需要采取一些手段解决碎片率过大的问题。
有下面三种方式可处理
重启Redis实例
重启Redis属于直接当时粗暴的方式，在重启之前要考虑两点：
• 若Redis的数据没有持久化，数据会丢失
• 即使做了持久化，重启需要通过AOF或RDB恢复数据，恢复时间取决于日志的大小，如果恢复时间长，这个阶段实例就不能提供服务了
这种方式还是要慎重！
memory purge手动碎片整理
手动整理内存碎片，会阻塞主进程，生产环境慎用。
memory purge 和 activedefrag回收的并不是同一块区域的内存，它简单粗暴的尝试清除脏页以便内存分配器回收。可以根据实际情况和activedefrag配合使用，memory purge在极端情况下效果较好，activedefrag则更彻底。
开启activedefrag自动碎片整理
在Redis 4.0 版本后新增配置项activedefrag，activedefrag默认关闭，计划清理碎片时需手动开启，命令如下：
127.0.0.1:6379> config set activedefrag yes
自动整理内存碎片，其原理是通过scan迭代整个Redis数据，通过一系列的内存复制、转移操作完成内存碎片整理，由于此操作使用的是主线程，故会影响Redis对其他请求的响应。
如上图碎片整理过程：
-
清理前，C和D之间多了2字节的内存碎片
-
清理过程：将B和D的数据分别拷贝到C和D之间的闲置空间，这样2个字节的闲置空间就形成了连续空间。当新应用要申请小于3个字节的空间时，这个闲置空间就能利用起来了
清理的条件
active-defrag-ignore-bytes 200mb：内存碎片占用的内存达到 200MB，开始清理；
active-defrag-threshold-lower 20：内存碎片的空间占比超过系统分配给 Redis 空间的 20% ，开始清理
