Redis内存碎片率过高（>1.5）本质是used_memory_rss远超used_memory，形成虚耗；需分三步处理：先结合绝对差值判断是否真需干预（如碎片>100MB），再启用可控自动整理（activedefrag yes等配置），最后通过数据结构优化、过期分散、大对象拆分等长期防控。
Redis内存碎片率过高（mem_fragmentation_ratio > 1.5）本质是操作系统分配给Redis的物理内存（used_memory_rss）远超其实际数据占用（used_memory），形成“看得见、用不上”的虚耗。这不是内存泄漏，但会提前触发淘汰策略、挤占系统资源，甚至引发OOM。处理需分三步：确认是否真需干预、启用可控清理、配合长期预防。
先判断：别被数字吓到，看绝对值再行动
仅看mem_fragmentation_ratio容易误判：
- ratio ：更危险——说明Redis内存不足，OS已启用swap，必须优先扩容或限流
- 1.0 ：正常范围，无需操作，持续监控即可
-
ratio > 1.5：需结合绝对差值判断——只有当
used_memory_rss - used_memory > 100MB时，才真正需要干预
例如：ratio=1.86，但used_memory=1GB，碎片仅0.86GB；若used_memory=10GB，碎片近9GB，就必须处理。
立即响应：启用自动碎片整理（activedefrag）
Redis 4.0+ 支持在线整理，但需四点齐备才生效：
- 确认版本 ≥ 4.0：
redis-cli INFO server | grep redis_version - 确认分配器为jemalloc：
redis-cli INFO memory | grep mem_allocator（libc不支持） - 在
redis.conf中写死配置，而非临时CONFIG SET（防被覆盖） - 确保实例有空闲CPU：QPS长期超2万、CPU持续95%以上时，整理几乎不触发
推荐配置段（加到redis.conf）：
activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
active-defrag-cycle-min 25
active-defrag-cycle-max 75
其中threshold-lower 10指碎片占used_memory_rss比例≥10%才启动，cycle-min/max控制整理时CPU占用在25%~75%，避免卡顿。
辅助手段：手动触发与紧急兜底
低峰期可执行MEMORY PURGE命令，强制释放jemalloc缓存的未使用内存。该操作会短暂阻塞主线程，适合夜间维护窗口。
若碎片率已突破2.0且自动整理无效，考虑滚动式重启：
- 对集群节点逐个下线—重载RDB/AOF—上线，利用重启时内存重分配天然“归零”碎片
- 单实例可先
BGSAVE，再SHUTDOWN SAVE后重启，确保数据不丢
注意：重启前务必确认持久化文件完整，且预留足够时间窗口。
长期防控：从数据写入源头减少碎片生成
碎片根子在频繁增删不同大小的数据，优化要落在日常操作上：
- 小键合并：避免成百上千个10字节字符串，改用Hash结构存储，启用
hash-max-ziplist-entries压缩编码 - 过期键分散：批量设置
EXPIRE时，附加随机秒数（如±300s），避免集中删除产生大空洞 - 大对象拆分：单值超10KB的数据，拆为多个带序号的key，或改用外部存储（如OSS）+ Redis存URL
- 淘汰策略匹配业务：读多写少用
allkeys-lfu，有时效性数据用volatile-lru，避免全量扫描压力
不复杂但容易忽略
