仅开启 active-defrag-enabled yes 不足以触发有效内存整理，需同步调高阈值（如 active-defrag-threshold-lower 12）、增大周期（active-defrag-cycle-min 100）、设忽略下限（active-defrag-ignore-bytes 100mb），并逐节点配置生效；集群需各节点单独设置且写入 redis.conf；整理对过期未清理 key 和小对象分散无效，须结合淘汰策略与合理 expire 使用。
active-defrag-enabled 设为 yes 就能自动整理内存？
不能。仅开启 active-defrag-enabled yes 不足以触发有效整理，Redis 默认的活跃整理阈值非常保守——active-defrag-threshold-lower 默认是 10（即内存碎片率 ≥10% 才考虑启动），而 active-defrag-cycle-min 默认仅 5（毫秒级 CPU 时间片），实际几乎不工作。
常见错误现象：启用了配置但 INFO memory 中 mem_fragmentation_ratio 长期卡在 1.8+，active_defrag_hits 几乎为 0。
- 必须同步调高整理敏感度：
active-defrag-threshold-lower 1.2（注意：这是百分比值 ×10，即 12% → 写 12；1.2% → 写 12） - 增大单次整理时长：
active-defrag-cycle-min 100、active-defrag-cycle-max 500 - 限制整理对主线程的影响：确保
active-defrag-ignore-bytes足够大（如100mb），避免小碎片反复触发整理
集群环境下各节点要单独配，不能靠 config rewrite 同步
Redis Cluster 节点间不共享配置，CONFIG SET 命令只作用于当前连接的节点，且重启后丢失。若只在某个 master 上执行，其他 master/slave 仍保持默认值，导致碎片整理不一致，部分节点持续膨胀。
使用场景：滚动升级或批量部署集群时，容易漏配从节点。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 逐节点登录并执行：
redis-cli -h node-ip -p port CONFIG SET active-defrag-enabled yes - 写入持久化配置：编辑每个节点的
redis.conf，显式添加全部相关项（不止 enabled） - 验证是否生效：
redis-cli INFO memory | grep -E "(mem_fragmentation_ratio|active_defrag)"，确认active_defrag_running偶尔为 1
整理效果受 value 大小和分配器影响极大
jemalloc（Redis 默认）支持内存归还，但 active defrag 仅对「已分配但未使用的页内空隙」做合并，无法解决「小对象分散在不同内存页」或「大对象长期占用导致后续分配被迫用新页」的问题。
典型表现：即使开启整理，mem_fragmentation_ratio 从 2.1 降到 1.6 后就停滞，used_memory_rss 下降不明显。
- value 平均大小
- 大量使用
HSET存储短 key+短 field，比SET更易产生内部碎片 - 若用 libc malloc（非推荐），
active-defrag完全无效——它依赖 jemalloc 的mallctl接口
别依赖 active-defrag 替代合理内存设计
它只是“止血贴”，不是“根治方案”。真实生产中，mem_fragmentation_ratio > 1.5 持续超过 1 小时，大概率说明数据模型或淘汰策略有隐患。
最容易被忽略的点：过期 key 清理不及时 + 淘汰策略为 noeviction 或 allkeys-lru 但 maxmemory 设置不合理，会导致已过期但尚未被扫描到的 key 占着内存，active defrag 对这类“逻辑存活、物理未释放”的内存无能为力。
- 检查
expired_keys和evicted_keys是否持续增长 - 确认
maxmemory-policy匹配业务语义（例如缓存场景慎用volatile-ttl） - 对写多读少、生命周期明确的数据，优先用
EXPIRE而非依赖后台惰性删除
