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，再决定是拆分、压缩还是换结构。