在使用 Redis 时,我们经常会遇到这样一个问题:明明做了数据删除,数据量已经不大了,为什么使用 top 命令查看时,还会发现 Redis 占用了很多内存呢?
实际上,这是因为,当数据删除后,Redis 释放的内存空间会由内存分配器管理,并不会立即返回给操作系统。所以,操作系统仍然会记录着给 Redis 分配了大量内存。
但是,这往往会伴随一个潜在的风险点:Redis 释放的内存空间可能并不是连续的,那么,这些不连续的内存空间很有可能处于一种闲置的状态。这就会导致一个问题:虽然有空闲空间,Redis 却无法用来保存数据,不仅会减少 Redis 能够实际保存的数据量,还会降低 Redis 运行机器的成本回报率。
打个形象的比喻。我们可以把 Redis 的内存空间比作高铁上的车厢座位数。如果高铁的车厢座位数很多,但运送的乘客数很少,那么,高铁运行一次的效率低,成本高,性价比就会降低,Redis 也是一样。如果你正好租用了一台 16GB 内存的云主机运行 Redis,但是却只保存了 8GB 的数据,那么,你租用这台云主机的成本回报率也会降低一半,这个结果肯定不是你想要的。
所以,这一次,我们就聊聊 Redis 的内存空间存储效率问题,探索一下,为什么数据已经删除了,但内存却闲置着没有用,以及相应的解决方案。
什么是内存碎片?
通常情况下,内存空间闲置,往往是因为操作系统发生了较为严重的内存碎片。那么,什么是内存碎片呢?
为了方便你理解,我还是借助高铁的车厢座位来进行解释。假设一个车厢的座位总共有 60 个,现在已经卖了 57 张票,你和 2 个小伙伴要乘坐高铁出门旅行,刚好需要三张票。不过,你们想要坐在一起,这样可以在路上聊天。但是,在选座位时,你们却发现,已经买不到连续的座位了。于是,你们只好换了一趟车。这样一来,你们需要改变出行时间,而且这趟车就空置了三个座位。
其实,这趟车的空座位是和你们的人数相匹配的,只是这些空座位是分散的,如下图所示:
我们可以把这些分散的空座位叫作“车厢座位碎片”,知道了这一点,操作系统的内存碎片就很容易理解了。虽然操作系统的剩余内存空间总量足够,但是,应用申请的是一块连续地址空间的 N 字节,但在剩余的内存空间中,没有大小为 N 字节的连续空间了,那么,这些剩余空间就是内存碎片(比如上图中的“空闲 2 字节”和“空闲 1 字节”,就是这样的碎片)。
那么,Redis 中的内存碎片是什么原因导致的呢?接下来,我带你来具体看一看。我们只有了解了内存碎片的成因,才能对症下药,把 Redis 占用的内存空间充分利用起来,增加存储的数据量。
内存碎片是如何形成的?
其实,内存碎片的形成有内因和外因两个层面的原因。简单来说,内因是操作系统的内存分配机制,外因是 Redis 的负载特征。</