Redis过期策略与内存淘汰机制协同工作：前者用惰性+定期删除处理到期数据，后者在maxmemory触发时按策略（如allkeys-lru）淘汰key；二者分属时间与空间维度，不可替代。
Redis 数据过期策略和内存淘汰机制是两套独立但协同工作的机制：前者解决“数据什么时候失效”，后者解决“内存不够时删谁”。它们不互为替代，而是分阶段配合——先靠过期策略清理自然到期的数据，再靠淘汰机制兜底应对内存压力。
过期策略：惰性 + 定期，双管齐下
Redis 不采用“一到时间就立刻删除”的定时删除（避免单线程阻塞），而是用两种轻量方式组合处理：
- 惰性删除：每次访问 key 前，Redis 检查它是否已过期；若过期，当场删除并返回 nil。优点是零额外 CPU 开销，缺点是冷数据可能长期滞留内存。
- 定期删除：默认每秒执行 10 次（由配置项 red">hz 控制），每次从过期字典中随机抽 20 个 key 检查，若其中过期比例超 25%，就再抽一轮，直到比例达标或单次耗时超 25ms 为止。它能主动释放一部分内存，但无法覆盖全部过期键。
注意：主库负责过期判断与触发 del 指令，从库只同步执行，存在短暂主从不一致风险；所有过期 key 都存于独立的 expires 字典，不影响主键空间查询效率。
内存淘汰机制：maxmemory 触发，按策略选删
当 Redis 实际内存使用达到 maxmemory 限制（如 maxmemory 256mb）时，写入新数据前会触发淘汰。策略通过 maxmemory-policy 配置，常见选项有：
- allkeys-lru：在全部 key 中淘汰最近最少使用的（推荐用于纯缓存场景）
- volatile-lru：只在设置了过期时间的 key 中淘汰 LRU 的（适合缓存+持久化混合场景，但需谨慎）
- volatile-ttl：只在带过期时间的 key 中，优先淘汰剩余存活时间最短的
- noeviction：默认策略，内存满则拒绝写入并报错（OOM），适用于强一致性要求场景
- allkeys-lfu：基于访问频次淘汰（Redis 4.0+ 支持），适合识别“低频但重要”的长尾数据
淘汰不是实时逐个扫描全量 key，而是采样（默认 5 个）后近似计算，兼顾性能与效果。
关键区别与协同逻辑
过期策略关注的是“时间维度”——键是否到了 TTL 终点；内存淘汰关注的是“空间维度”——当前能否腾出位置写新数据。
- 一个 key 即使已过期，若未被惰性检查或定期扫描抽中，仍会留在内存中，直到淘汰机制启动时才可能被顺带清掉（取决于所选策略是否覆盖它）
- 如果用了
noeviction策略，过期键不及时清理 + 内存打满，就会直接写失败；所以生产环境通常搭配allkeys-lru或volatile-lru，并合理设置hz（建议 10–25） - 大量 key 同一时刻过期（比如批量设了相同 EXPIREAT）会加剧定期删除循环，导致 CPU 短时飙升、响应延迟，应主动加随机偏移（如 ±300 秒）分散过期时间
基本上就这些。理解清楚这两层机制的分工和边界，才能避免缓存击穿、内存溢出或误删有效数据的问题。
