内存碎片类似上面高铁座位的例子。虽然操作系统的剩余空间总量足够，但申请一块连续地址空间n字节时，剩余内存空间中没有大小为n字节的连续空间，那么这些剩余空间就是内存碎片。
redis的这种机制，提高了内存的使用率，但是会使redis中有部分自己没在用，却不释放的内存，导致了内存碎片的发生。
内存分配器在编译时指定的redis使用的内存分配器，可以是libc、jemalloc、tcmalloc，默认是jemalloc。
jemalloc在64位系统中，将内存空间划分为小、大、巨大三个范围；每个范围内又划分了许多小的内存块单位；存储数据的时候，会选择大小最合适的内存块进行存储。
jemalloc划分的内存单元如下图所示：
也就是说redis是以指定大小的块为单位进行连续内存分配的，而不是按需分配的。redis 会根据申请的内存最接近的固定值分配相应大小的空间。
这就好比你有多个箱子，需要用来装物品。你需要找到一个体积最接近的箱子来挑选。如果你发现在你把东西放进去后还有一些空间，你就不需要再去找箱子了。但是，这种分配空间的方式会带来一定程度的内存碎片。不同大小的划分空间可以被视为具有不同体积的盒子，每个盒子内的空间都有不同程度的剩余。这些剩余的空间就是内存碎片。
怎么看是否有内存碎片？我们登陆到redis服务器上，执行以下命令：
redis> info memory
我们会看到这些信息：
指标mem_fragmentation_ratio:1.86 表示当前的内存碎片率。
mem_fragmentation_ratio = used_memory_rss / used_memory
redis申请的内存会被操作系统标记为used_memory_rss。 used_memory：是redis中的数据占用的内存。
所以，mem_fragmentation_ratio=1应该是最理想的情况
碎片率的意义？mem_fragmentation_ratio的不同值，说明不同的情况。
大于1：说明内存有碎片，一般在1到1.5之间是正常的。
大于1.5：说明内存碎片率比较大，需要考虑是否要进行内存碎片清理，要引起重视。
小于1：说明已经开始使用交换内存，也就是使用硬盘了，正常的内存不够用了，需要考虑是否要进行内存的扩容，使用swap是相当影响性能的。
清理内存碎片低于4.0-rc3版本的redis如果你的redis版本是4.0-rc3以下的，redis服务器重启后，redis会将没用的内存归还给操作系统，碎片率会降下来。
高于4.0-rc3版本的redis从redis4.0-rc3版本开始，内存碎片整理可以在线上进行而无需重启。 自动碎片清理，只要设置了如下的配置，内存就会自动清理了。
redis> config set activedefrag yes
自动清理内存碎片的功能需要该redis的内存分配器是jemalloc时才能启用。
启用后需要同时满足下面2个参数的设置条件时才会触发自动清理
active-defrag-ignore-bytes 100mb # 默认100mb,表示内存碎片空间达到100mb时active-defrag-threshold-lower 10 # 默认10，表示内存碎片空间占os分配给redis的物理内存空间的比例达到10%时
主线程在执行内存碎片自动清理时会耗费cpu资源，因为redis采用单进程模型。为了避免自动清理降低redis的处理性能，如下两个参数可以控制清理动作消耗的cpu时间比例的上下限。
active-defrag-cycle-min 5 : 默认5，表示自动清理过程所用 cpu 时间的比例不低于5%，保证清理能正常开展；active-defrag-cycle-max 75: 默认75，表示自动清理过程所用 cpu 时间的比例不高于 75%，一旦超过，就停止清理，从而避免在清理时，大量的内存拷贝阻塞 redis，导致响应延迟升高。
如果你对自动清理的效果不满意，可以使用如下命令，直接试下手动碎片清理：
redis > memory purge
需要注意的是，该清理命令也只当redis的内存分配器是jemalloc时才能生效
#碎片整理总开关activedefrag yes #当碎片达到 100mb 时，开启内存碎片整理active-defrag-ignore-bytes 100mb #当碎片超过 10% 时，开启内存碎片整理active-defrag-threshold-lower 10 #内存碎片超过 100%，则尽最大努力整理active-defrag-threshold-upper 100 #内存自动整理占用资源最小百分比active-defrag-cycle-min 5 #内存自动整理占用资源最大百分比active-defrag-cycle-max 50
pipeline管道为什么需要pipelineredis客户端执行一条命令分4个过程：
发送命令－〉命令排队－〉命令执行－〉返回结果
这个过程称为 round trip time(简称rtt, 往返时间) ，mget mset有效节约了rtt，但大部分命令（如hgetall，并没有mhgetall）不支持批量操作，需要消耗n次rtt ，这个时候需要pipeline来解决这个问题
在pipeline模式中，命令被写入缓冲区，最后通过exec命令一次性发送给redis执行，并返回执行结果。
1、未使用pipeline执行n条命令
2、使用了pipeline执行n条命令
原生批命令(mset, mget)与pipeline对比原生批命令是原子性，pipeline是非原子性
原生批命令一命令多个key, 但pipeline支持多命令，pipeline 不支持事务，因为命令是一条一条执行的。
原生批命令是服务端实现，而pipeline需要服务端与客户端共同完成
pipeline的优缺点pipeline 每批打包的命令不能过多，因为 pipeline 方式打包命令再发送，那么 redis 必须在处理完所有命令前先缓存起所有命令的处理结果。这样就有一个内存的消耗。
pipeline 操作是非原子性的，如果要求原子性的，不推荐使用 pipeline
使用pipeline组装的命令个数不能太多，不然数据量过大，增加客户端的等待时间，还可能造成网络阻塞，可以将大量命令的拆分多个小的pipeline命令完成。
一些疑问pipeline 执行多少命令合适？
根据官方的解释，推荐是以 10k 每批 (注意：这个是一个参考值，请根据自身实际业务情况调整)。
pipeline 批量执行的时候，是否对redis进行了锁定，导致其他应用无法再进行读写？
redis 采用多路i/o复用模型，非阻塞io，所以pipeline批量写入的时候，一定范围内不影响其他的读操作。
在编码时请注意，pipeline 期间将“独占”链接，此期间将不能进行非“管道”类型的其他操作，直到 pipeline 关闭；如果你的 pipeline 的指令集很庞大，为了不干扰链接中的其他操作，你可以为 pipeline 操作新建 client 链接，让 pipeline 和其他正常操作分离在2个 client 中。
相关代码 @test void pipeline() { list<object> result = redistemplate.executepipelined((rediscallback<string>) connection -> { for (int i = 0; i < 100; i++) { redistemplate.opsforvalue().set("pipel:" + i, i); } return null; }); }
以上就是redis内存碎片产生原因及pipeline管道原理是什么的详细内容。