Redis淘汰策略需在maxmemory启用后才生效，通过config get maxmemory确认是否设限，info memory中evicted_keys增长表明策略运行；allkeys-lru与volatile-lru区别在于候选集范围，前者涵盖所有key，后者仅限设过期时间的key。
Redis 不会自动“优化”存储空间，它只在 maxmemory 触发后按策略被动释放内存；所谓“优化”，本质是选对淘汰策略 + 控制数据生命周期，而不是让 Redis 主动压缩或整理。
怎么确认当前淘汰策略是否生效
很多用户改了 maxmemory-policy 却没效果，根本原因是没真正触发淘汰条件——Redis 只在写入新数据且内存即将超限时才执行淘汰逻辑。
- 先检查是否设置了
maxmemory：运行config get maxmemory，返回0表示未启用内存限制，所有淘汰策略都不起作用 - 再确认当前策略：运行
config get maxmemory-policy，确保不是默认的noeviction - 观察淘汰行为：执行
info memory，重点关注evicted_keys字段是否持续增长；为零说明没淘汰，可能因为内存还没真正打满，或 key 全都没设过期时间（比如用了volatile-lru但所有 key 都永不过期）
allkeys-lru 和 volatile-lru 的关键区别在哪
区别不在“算法”，而在“候选集”。LRU 在 Redis 中都是近似实现（随机采样 + 比较访问时间），性能开销几乎一致；真正影响效果的是你允许它从哪批 key 里挑。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
allkeys-lru：所有 key 都参与竞争，包括永不过期的配置项、计数器等。适合缓存场景，但风险是把重要长期数据也淘汰掉 -
volatile-lru：只看expires字典里登记过的 key。如果业务中大量 key 忘记设expire，那这个策略实际候选集可能为空，退化成noeviction—— 此时写入会直接报错(error) OOM command not allowed when used memory > 'maxmemory' - 验证方式：用
scan 0 match * count 1000批量查 key，再对每个 key 执行ttl，统计返回-1（永不过期）和非负数的比例
为什么 volatile-ttl 看似合理却容易误伤
volatile-ttl 不是“优先保留热点数据”，而是无差别地清掉马上要过期的 key，不管它刚被访问过还是沉寂已久。
- 典型误用场景：登录 session 设置了 30 分钟过期，但用户中途刷新页面，
refresh接口顺手又调了一次expire session_key 1800，导致 TTL 重置为 1800 秒；而另一个 5 分钟后过期的验证码 key 却被优先淘汰，造成用户收不到新验证码 - 它不感知访问频次或时间，只比数字大小，所以高并发下可能批量清除一批“刚好快过期”的活跃 key
- 仅建议用于纯临时数据，如短期任务 ID、一次性 token，且必须配合短 TTL（比如 60 秒内）和明确的业务清理逻辑
LFU 策略需要特别注意衰减周期
Redis 的 allkeys-lfu 或 volatile-lfu 不是简单计数，而是带时间衰减的频率统计，避免历史高频访问长期压制新热点。
- 衰减由
lfu-decay-time控制（单位：分钟），默认是 1。意味着每 1 分钟，所有 key 的访问频次计数器除以 2（向下取整）。如果业务冷热切换周期长于这个值，旧热点会快速失权；如果太短（比如设成 0.1），新 key 还没积累够次数就被淘汰 - 调整后需用
config rewrite持久化，否则重启丢失 - 验证 LFU 效果不能只看
object freq，要结合info stats中的lfu_hits和lfu_misses对比命中率变化
淘汰策略本身不解决数据设计问题。最常被忽略的一点是：如果你的 key 大量使用哈希表（HSET）存千级字段，或列表（LPUSH）堆积万级元素，单个 key 占用内存远超预期——这时再好的 LRU/LFU 也只是在“救火”，而非“优化”。先用 memory usage 定位大 key，再决定是拆分、压缩还是换结构。
