Redis的String类型加剧内存碎片是因为频繁SET/GET/APPEND导致jemalloc中大小不一的内存块反复分配释放，旧块无法复用而残留为碎片，表现为mem_fragmentation_ratio>1.5且used_memory_rss远大于used_memory。
为什么Redis的String类型会加剧内存碎片？
Redis默认用jemalloc管理内存，但String类型频繁的SET/GET/APPEND操作会导致大量小内存块反复分配释放。jemalloc虽有内存池机制，可一旦出现大小不一的写入（比如先存1KB字符串，再覆盖成1MB），旧内存块无法被复用，就会残留为不可用的碎片。
典型现象是：INFO memory 中 mem_fragmentation_ratio 持续 > 1.5，同时 used_memory_rss 远大于 used_memory —— 这说明OS层已分配但Redis无法有效利用的内存越来越多。
如何确认当前使用的内存分配器？
直接查Redis启动日志或运行时信息：
redis-cli INFO server | grep mem_allocator
输出类似 mem_allocator:jemalloc-5.2.1 即表示正在使用jemalloc；若为 libc，则是系统malloc，通常更易碎片化且无自动归还机制。
- jemalloc 是 Redis 编译时默认启用的，但某些Docker镜像或手动编译未加
--with-jemalloc可能回退到libc - macOS上默认用
libc，因为jemalloc在macOS存在兼容性问题，此时碎片问题更明显 - 不能通过配置文件切换分配器，必须重新编译Redis并指定
--with-jemalloc或--with-mimalloc
mimalloc比jemalloc更适合String密集场景吗？
在高频率小对象写入（如短key+短value的计数器、session缓存）下，mimalloc 的每线程内存池 + 更激进的空闲块合并策略，确实能压低mem_fragmentation_ratio均值约0.2–0.4。但它对大块内存（>2MB）的延迟略高，若业务中常存大String（如序列化后的图片元数据），反而可能增加单次SET延迟。
实操建议：
- 编译时加
--with-mimalloc（需提前安装mimalloc开发库） - 上线前用
redis-benchmark -n 1000000 -t set,get -r 10000 -d 128对比两版的mem_fragmentation_ratio和P99延迟 - 避免混用：不要在已有jemalloc实例上热替换，必须重启，且RDB/AOF加载期间仍走原分配器路径
不换分配器，仅靠配置能缓解String碎片吗？
不能根治，但可减少恶化速度。关键不是调maxmemory，而是控制String生命周期和写入模式：
- 禁用
append命令：它总在原内存后追加，极易触发realloc失败+旧块泄漏，改用set重写 - 对时效性弱的String，设
EXPIRE而非依赖LRU淘汰——主动释放比被动回收更可控 - 避免用String存JSON等变长结构；固定长度字段（如用户状态码）用Hash的
hset user:1001 status 1更省内存且不易碎片 -
activedefrag yes在Redis 4.0+可用，但仅对“可移动”的键生效（String本身支持，但若value被其他数据结构引用则跳过）
真正棘手的是：当mem_fragmentation_ratio > 2.0 且持续上升，说明已有大量零散页无法合并，此时除了重启实例，没有在线修复手段。
