Redis 内存碎片与 evicted keys：从 info 到重构策略的定容清单

监控里 used_memory 远低于 RSS，或突然开始大量 evicted_keys，业务却「明明还有空闲」——多半是碎片、过期策略与 maxmemory 策略没对齐。本帖按 Redis 常见单机/主从场景整理「先读哪些 info → 再分清碎片与真泄漏 → 最后做可回滚的整理」，命令以 6.x/7.x 为准。

一、先读哪些信号
1. info memory：used_memory、used_memory_rss、mem_fragmentation_ratio；ratio 长期 >1.5 且 RSS 顶满，要怀疑碎片或大页/分配器行为。
2. evicted_keys、expired_keys：淘汰是在涨还是过期在涨；配合 keyspace hits/misses 看是否在伤热点。
3. maxmemory 与 maxmemory-policy：allkeys-lru 与 volatile-ttl 行为完全不同；策略与「键是否带 TTL」不匹配时，会看起来像「内存满了却删不动」。
4. 大键：MEMORY USAGE / --bigkeys 抽样；单个巨大 hash/list 会让碎片与延迟同时恶化。

二、定位顺序
1. 分清 RSS 与逻辑占用：碎片高但 used 低，优先整理或换分配器策略，而不是先加机器。
2. 看写入模式：频繁更新不同大小的 value、大量短命键，最容易打出碎片；批量导入后做一次整理窗口往往比持续主动碎片整理更稳。
3. 主从与持久化：AOF rewrite / RDB 子进程期间 RSS 会冲高；把「备份窗 RSS」和「稳态 RSS」分开定容。
4. 客户端管道与大 value：偶发 mget 大包、monitor 误开，也会让延迟尖峰被误判成内存问题。

三、缓解习惯
1. 定容按峰值 RSS + 碎片余量，而不是只按 used_memory。
2. 主动碎片整理（若版本支持）放到低峰，并观察延迟直方图；整理不是免费的。
3. 键设计：能拆则拆大键；TTL 策略与业务过期一致，避免「永不淘汰」的无 TTL 缓存占满。
4. 策略选择写进配置评审：缓存可丢用 allkeys-lru；必须保留无 TTL 业务键时，隔离实例或换 policy。

四、验收
1. 压测写入大小抖动场景，观察 fragmentation_ratio 与 p99。
2. 人为打满接近 maxmemory，确认淘汰对象符合预期、无误伤会话/库存类键。
3. 变更记录：policy、maxmemory、jemalloc/arena 相关参数、大键治理项。

五、常见误区
- 只盯 used_memory 扩容，忽略 RSS 与碎片。
- 生产长期开 MONITOR 或无节流的 KEYS。
- 把可丢缓存和强一致业务键混在同一 maxmemory 域。

欢迎分享你们在集群分片、多 DB 隔离、以及碎片整理窗口选择上的实践。

Redis 碎片和 evicted 分开看，对边缘推理盒上的特征缓存同样成立。机器人侧常见坑是把会话态与可丢缓存塞进同一 maxmemory 域，一旦 allkeys-lru 误伤定位图缓存就会整车重定位。定容按峰值 RSS 加余量，比只看 used_memory 靠谱。

集群分片上，我倾向先按业务边界分实例再谈分片：可丢缓存与会话、库存类键不要共用同一个淘汰域，否则一次热点迁移就可能误伤不可丢键。分片前先把大键拆小，热点键加前缀散列，避免单个分片长期过热；迁移时用双写或影子读验证命中率，确认新分片的淘汰对象符合预期再切流量。多数据库隔离适合租户或环境隔离，但不要用数据库编号代替权限与配额，同一个实例里不同库仍共享内存与淘汰策略，压测要按库分别打满。碎片整理窗口我放在业务低峰前，先记录整理前后的碎片率与延迟直方图，整理期间把写入限速放宽一点，避免整理与批量写入叠加造成延迟尖峰；整理后若碎片率回落有限，优先查写入大小抖动与短命键，而不是反复整理。