诡异的 Redis 数据库内存，空间很大，内存使用还是不理想
图注：思维导图
[](
)查看内存使用情况
===========================================================
====================
首先想要知道 Redis 内存的使用情况，我们就需要获取相关的信息。
Redis 中查看内存相关信息是很简单的，只需要在命令行输入『info memory』就可以看到各种相关数据。在这里我罗列了一些较为重要的参数：
used_memory：已经使用了的内存大小。
used_memory_rss：redis 物理内存的大小。
mem_fragmentation_ratio：内存碎片率。
这里有一个内存碎片率的名词需要关注下，它可以用来表示当前的内存使用情况。
具体计算方式：
对于内存碎片率，一般保持在?1~1.5?之间是最合理的。
[](
)什么是内存碎片
==============================================================================
了解了内存碎片率，那什么是内存碎片呢？
定义是这样的：由于一块连续空闲的空间比所要申请的空间小，导致这块空间不可用，对于内存整体来说就是内存碎片。
举个例子：
假设有一块 100MB 的连续空闲内存空间，你每次都会从中申请一块 30MB 的内存。那么当你申请了 3 次后，这块内存就只剩下了 10MB 的空间，第 4 次申请的时候就会失败。如果没有其它的空间释放并且每次申请的空间都比 10MB 大，那么剩下的空间对于整块内存来说就是内存碎片。
[](
)导致内存碎片的原因
================================================================================
Redis 中，最常用的是写入、修改、删除数据。这些操作在执行后都会产生 一定程度的内存碎片。
[](
)写入数据
Redis 中分配内存是根据固定的大小来划分内存空间的。为了减少分配次数，Redis 会根据申请的内存最接近的固定值分配相应大小的空间。
什么意思呢，假如 Redis 按照 8 字节、16 字节、32 字节、48 字节等来分配内存。当你想要存储一个 18 字节的数据时，此时 Redis 就会分配 32 字节（因为 32 是与 18 最接近的固定值）。如果这时候，再写入的数据需要的内存空间在 14 个字节内，那 Redis 就无需再进行分配了。
这就像你有不同的箱子，为了装东西，你需要找一个体积最接近的箱子来装。但是装进去后，你发现还有空间可以放一些小东西，就无需再找箱子了。
但是，这种分配空间的方式会带来一定程度的内存碎片。我们可以把固定大小的划分空间看成不同体积的箱子，每种箱子里的空间不同程度上都会有剩余。这些剩余的空间就是内存碎片。
[](
)修改数据
键值对进行修改时，可能会变大也会变小，相应的就会占用额外空间或者释放不用的空间。
如图中所示，当前 A、B、C 分别占用了 3、2、4 个字节，将 A 从 3 字节修改为 2 字节时，此时就会有 1 个字节的空间空了出来，这时就会出现 1 个字节的碎片。
那如果我将数据 A 从 3 字节修改为 4 字节呢？此时为了保持数据 A 的空间连续性，操作系统会把 B 拷贝到别的空间。此时又会出现 1 个字节的碎片。
[](
)删除数据
理解了修改数据，删除数据就很容易明白了。还是上边的例子，此时删除了数据 B，那么就释放了 2 个字节的空间。这样对于整个内存空间来说就产生了 2 个字节的碎片。
[](
)如何解决内存碎片
===============================================================================
你可能会有疑问，内存碎片会有什么危害呢？
我们还是以上边的箱子来表示。你想想，如果你要把这些箱子都装上车运走，每个箱子里都有空出来的空间（内存碎片），那么运行一次的效率及性价比是不是会很低。同样，在 Redis 中，由于大量的碎片存在，会导致实际利用率变低。
那么我们有没有办法来解决内存碎片呢？
[](
)推倒重来
第一种方式很简单，直接推倒重来。也就是把 Redis 直接重启完事儿，内存一断电全世界就清净。但是这种暴力省事的方式却有很多隐患。
生产环境中你这么搞的话得提前烧烧香，保佑不会出什么问题。如果你没进行过持久化，那么就别烧了，烧了也没用。如果有持久化的话，那么恢复时长还得取决你持久化文件的大小，在这个阶段还无法提供服务。糟心不？
[](
)空间置换
那么有没有不这么刺激的方式。
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论