共计 3232 个字符，预计需要花费 9 分钟才能阅读完成。
本文已收录至 GitHub，举荐浏览 👉 Java 随想录
微信公众号：Java 随想录
原创不易，重视版权。转载请注明原作者和原文链接
在咱们探索和优化 Redis 性能的过程中，「Redis 内存碎片」是一个不可漠视的话题。
这篇文章将深入研究这个看似微不足道，但实际上对 Redis 运行效率产生重要影响的问题。首先，让咱们揭开 Redis 内存碎片的神秘面纱，了解它的实质及其为何成为咱们必须面对的挑战。
内存碎片如何产生的
Redis 内存碎片次要是因为 Redis 数据存储和回收过程中的内存治理问题导致的。
Redis 分配内存时，会依据须要申请一段间断的内存空间。但当 Redis 删除或批改数据时，开释的内存空间并不一定能被立刻从新利用，尤其是当这些闲暇内存空间大小不统一时，就可能导致内存碎片的呈现。
为了进步内存应用的效率，Redis 外部应用内存分配器来对内存的申请和开释进行治理。Redis 应用的内存分配器默认是「jemalloc」。
而内存分配器是依照固定大小来分配内存的，并不是齐全依照程序申请的内存大小来进行调配。
比方程序申请一个 20 字节的内存，内存分配器会调配一个 32 字节的内存空间，这么做是为了缩小调配次数。redis 会申请不同大小的内存空间来存储不同业务不同类型的数据，因为内存依照固定大小调配且会比理论申请的内存要大一些，这个过程中会产生内存碎片。
举个生存中的例子，帮忙大家了解：
假如你正在整顿一间图书馆。图书馆的书架就像是 Redis 贮存数据的内存空间。每本书都代表不同大小的数据。刚开始时，你把所有的书都依照大小放好。小书在一侧，大书在另一侧。这样你能够无效地利用书架的空间，也不便找书。
然而，如果你须要移除一些书（删除某些数据），而后又退出新的书（新增数据），就可能呈现问题了。例如，你移除了一些大书，把它们的地位空进去，而后把新的小书放进去。这样下来，本来属于大书的空间，当初只被小书局部占用，残余的空白就成了“内存碎片”。
又或者你有一堆新的大书要放，但书架上只有扩散的小书的空位，无奈包容这些大书。这个时候你可能须要重新排列整个书架（相似于 Redis 的内存整理）去腾出间断的大片空间来摆放这些新的大书。
总结来说：当数据一直删除和新增时，内存中空出的地位可能无奈齐全匹配新数据的大小，导致产生未被利用的“碎片”空间，这就是内存碎片。
内存分配器
Redis 应用内存分配器来治理其在运行期间须要应用的内存资源。能够是 libc、jemalloc、tcmalloc。默认是 jemalloc。
要指定 Redis 应用哪个内存分配器，你须要在编译 Redis 时做出抉择。通常在执行 make 命令时能够通过 MALLOC 参数来指定。例如，如果你想应用 jemalloc，你能够像这样编译 Redis：make MALLOC=jemalloc。
jemalloc 在 64 位零碎中，将内存空间划分为小、大、微小三个范畴。每个范畴内又划分了许多小的内存块单位，存储数据的时候，会抉择大小最合适的内存块进行存储。
jemalloc 划分的内存单元如下图所示：
也就是说 Redis 是以指定大小的块为单位进行间断内存调配的，而不是按需分配的，Redis 会依据申请的内存最靠近的固定值调配相应大小的空间。
这就像你有不同的箱子，为了装货色，你须要找一个体积最靠近的箱子来装。然而装进去后，你发现还有空间能够放一些小东西，就无需再找箱子了。
然而，这种调配空间的形式会带来肯定水平的内存碎片。咱们能够把固定大小的划分空间看成不同体积的箱子，每种箱子里的空间不同水平上都会有残余。这些残余的空间就是内存碎片。
怎么看是否有内存碎片
咱们登陆到 Redis 服务器上，执行以下命令，这会返回一段形容 Redis 内存应用状况的文本。
redis> info memory咱们会看到相似如下的信息：
在这里，咱们次要关注的是名为 mem_fragmentation_ratio 的字段，它显示了 Redis 内存碎片的比例。
如果 mem_fragmentation_ratio 大于 1，那就示意存在内存碎片。这个值越大，内存碎片就越多。如果该值十分靠近 1 或者小于 1，则示意内存碎片很少或者没有。
计算公式为：
mem_fragmentation_ratio = used_memory_rss / used_memory其中：
used_memory_rss：代表 Redis 过程占用的总物理内存大小（包含码区、数据区和堆栈等），单位是字节。used_memory：代表 Redis 分配器申请的内存总量，也就是从操作系统角度看过程理论应用的虚拟内存空间，单位是字节。
碎片率的意义
mem_fragmentation_ratio的不同值，阐明不同的状况。
- 大于 1：阐明内存有碎片，通常在 1 到 1.5 之间是失常的。
- 大于 1.5：阐明内存碎片率比拟大，须要思考是否要进行内存碎片清理，要引起器重。
- 小于 1：阐明曾经开始应用替换内存，也就是应用硬盘了，失常的内存不够用了，须要思考是否要进行内存的扩容，应用 swap 是相当影响性能的。
清理内存碎片
低于 4.0-RC3 版本的 Redis
Redis 4.0-RC3 之前的版本并没有内置的内存碎片整顿工具。如果你想要清理内存碎片，能够通过重启的形式。
当 Redis 重新启动时，它会通过 RDB 长久化性能将数据存储到磁盘，而后再从磁盘加载数据到内存，这个过程能够无效地清理内存碎片。但这种办法会导致服务的长期中断。
高于 4.0-RC3 版本的 Redis
Redis4.0-RC3 版本开始，引入了active-defrag 个性。能够在不重启的状况下，主动进行碎片清理。
开启配置如下，此选项的默认值是敞开的，激活碎片整顿可能会占据一些 CPU 工夫。
redis> config set activedefrag yes 留神：主动清理内存碎片的性能须要该 Redis 的内存分配器是 jemalloc 时能力启用。
启用后须要同时满足上面 2 个参数的设置条件时才会触发主动清理
active-defrag-ignore-bytes 100mb # 默认 100MB, 示意内存碎片空间达到 100MB 时
active-defrag-threshold-lower 10 # 默认 10，示意内存碎片空间占 OS 调配给 redis 的物理内存空间的比例达到 10% 时redis 是单过程模型，内存碎片主动清理是通过主线程操作的，也会耗费肯定的 CPU 资源。为了防止主动清理升高 Redis 的解决性能，如下两个参数能够管制清理动作耗费的 CPU 工夫比例的上上限：
active-defrag-cycle-min 5 # 默认 5，示意主动清理过程所用 CPU 工夫的比例不低于 5%，保障清理能失常发展；active-defrag-cycle-max 75 # 默认 75，示意主动清理过程所用 CPU 工夫的比例不高于 75%，一旦超过，就进行清理，从而防止在清理时，大量的内存拷贝阻塞 Redis，导致响应提早升高。如果你对主动清理的成果不称心，能够应用如下命令，间接进行手动碎片清理：
redis > memory purge须要留神的是，该命令会阻塞主过程，并且目前也仅实现了 jemalloc 作为内存分配器的内存统计，对其余分配器暂不反对。
本篇文章到这就完结了。在咱们深入研究 Redis 内存碎片治理和优化策略后，能够明确一点：了解并正当解决内存碎片化对于保障 Redis 的性能及稳定性至关重要。
不论是进行内存调配策略的调整，还是应用适当的数据结构，都是对 Redis 内存治理的优化。
同时，定期的监控和扫视也是必不可少的步骤。心愿本文能为你在解决 Redis 内存碎片问题上提供一些有价值的启发。记住，每一个优良的工程师都应该以了解其应用的工具为荣。让咱们继续关注和优化 Redis，使其更好地服务于咱们的我的项目，推动业务的倒退。
感激浏览，如果本篇文章有任何谬误和倡议，欢送给我留言斧正。
老铁们，关注我的微信公众号「Java 随想录」，专一分享 Java 技术干货，文章继续更新，能够关注公众号第一工夫浏览。
