真正有效的内存碎片治理需三步：先确认碎片真实超标（mem_fragmentation_ratio>1.5且used_memory_rss-used_memory>100MB），再确保activedefrag四参数配齐并生效，最后选对淘汰策略（allkeys-lru/LFU优于volatile-lru）辅助控碎。
Redis内存碎片率高 + 淘汰频繁，不是单靠换淘汰策略就能解决的；真正有效的做法是：先确认是否真碎片高（看绝对值），再确保activedefrag能跑起来，最后才调淘汰策略辅助控碎。光改maxmemory-policy却不管active-defrag-ignore-bytes或mem_allocator，大概率白忙。
怎么判断是不是真碎片高，而不是误报？
别只信mem_fragmentation_ratio一个数。这个比值会误导人——比如used_memory才2GB，ratio=1.8，碎片才1.6GB；但若used_memory是25GB，ratio=1.8，碎片就近20GB，必须动。
- 必须同时满足两个条件才算“该干预”：
mem_fragmentation_ratio > 1.5且used_memory_rss - used_memory > 100mb -
used_memory_rss远大于used_memory但ratio vm.swappiness和系统内存压力 -
redis-cli INFO memory | grep mem_allocator返回libc？那activedefrag压根不生效，jemalloc才是前提
为什么开了activedefrag yes却没反应？
Redis 7.0 的自动碎片整理不是“一开就转”，它极度依赖运行时资源空闲。常见失效场景不是配置错，而是根本没抢到执行机会。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redis-cli INFO memory | grep active_defrag_running返回0→ 当前没在整理，不是功能坏，是被CPU卡住了 - QPS持续 >15k 或 CPU ≥90%？
activedefrag会主动让出CPU，等空闲了才干活 - 配置被覆盖：运维脚本、配置中心、
redis.conf里写的是no，CONFIG SET临时生效也顶不住重启后还原 - 漏配关键阈值：
active-defrag-ignore-bytes 100mb和active-defrag-threshold-lower 10没设，即使碎片高也不会触发
allkeys-lru为什么比volatile-lru更利于控碎片？
本质是淘汰对象的“体积分布”不同。碎片恶化主因不是淘汰动作本身，而是淘汰后释放的内存块太小、太散，jemalloc没法合并重用。
-
volatile-lru只能从带EXPIRE的键里选，而这类键往往是短生命周期小缓存（如token:abc、sess:123），淘汰100个1KB字符串，留下100个零碎空洞 -
allkeys-lru可淘汰任意键，包括冷的大哈希（几百KB）、大ZSET，一次释放连续大块内存，jemalloc更容易回收或归还给OS - 业务里有大量永久键（如配置项）？
allkeys-lfu更稳——它对“长期低频但体积大的对象”识别更准，避免误删热点小键 - 切忌在无过期键场景下配
volatile-*策略，此时实际退化为noeviction，写入失败但碎片照涨
淘汰策略只是辅助，真正降碎片靠这三件事
淘汰策略选得再好，也只是“不让碎片越积越多”；想把已有的碎片收回来，得靠底层协同。
-
activedefrag必须配齐四参数：activedefrag yes+active-defrag-ignore-bytes 100mb+active-defrag-threshold-lower 10+active-defrag-cycle-min 25/active-defrag-cycle-max 75 - 数据结构压缩不能省：
hash-max-ziplist-entries和hash-max-ziplist-value要按实际字段大小调大，否则200个10字节字段会被拆成多个小分配单元，徒增内部碎片 - jemalloc参数要调：
dirty_decay_ms和muzzy_decay_ms建议设为1000（默认是0），加快脏页回收；vm.overcommit_memory=1也要开，避免OS过度保守
最容易被忽略的一点：activedefrag整理的是**已释放但未归还的内存块**，它无法合并正在使用的对象之间的空隙。所以如果业务持续高频写入大量bigkey又立刻删，碎片还是会快速回升——这时候得先管住bigkey，再谈整理。
