volatile-lru和allkeys-lru的核心区别在于淘汰范围与数据安全性：前者仅淘汰设置了过期时间的键，保护永不过期的关键数据；后者对所有键一视同仁，适用于纯缓存场景。
volatile-lru 和 allkeys-lru 的核心区别在「淘汰范围」和「数据安全性」，不是算法不同，而是“对谁下手”完全不同。
作用范围：只管带过期时间的键 vs 全体无差别对待
volatile-lru 只在设置了 EXPIRE 或 PEXPIRE 的键中找最近最少使用的来淘汰；没设过期时间的键，哪怕内存爆了也完全不动它。
allkeys-lru 则不管有没有 TTL，所有键都在候选池里，只要内存不够，就从全部键中挑 LRU 值最小的那个淘汰。
- 比如你存了用户 session（设了 30 分钟过期）和系统配置（
CONFIG SET写入，永不过期），用 volatile-lru 就只动 session，配置稳如泰山 - 换成 allkeys-lru，系统配置可能某次采样就被抽中，直接被踢出——服务立刻异常
实际行为差异：可能完全不淘汰 vs 持续淘汰
如果实例里所有 key 都没设过期时间，volatile-lru 实际上会退化为 noeviction：内存超限后写操作全报错 OOM command not allowed。
allkeys-lru 则始终有淘汰能力，只要内存满就会动手，不会卡住写入。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- volatile-lru 更适合混存场景：缓存 + 永久配置 + 元数据共存
- allkeys-lru 更适合纯缓存场景：CDN 后端、API 响应缓存、所有数据都可重建
LRU 实现细节：都不是标准链表，而是采样近似
两者底层用的都是 Redis 的近似 LRU 算法：每个 key 只存一个 24-bit 的 lru 时间戳（分钟级精度），淘汰时随机采样 maxmemory-samples 个 key（默认 5 个），从中挑 lru 值最小的淘汰。
所以都不是严格按访问顺序淘汰，但采样越多越接近理想效果，代价是 CPU 占用上升。
- 调高
maxmemory-samples（比如到 10）能提升淘汰合理性，尤其对周期性访问的 key（如每天凌晨刷一次的报表）更友好 - 采样太小（如设为 1）基本等于随机淘汰，LRU 名存实亡
选错的典型后果
误用 allkeys-lru 在含重要永不过期数据的实例上，会导致关键配置、白名单、路由规则等被误删，引发线上故障。
反过来，volatile-lru 用在全量 key 都带 TTL 的场景下，虽然安全，但语义不如 allkeys-lru 清晰——因为所有 key 都可淘汰，没必要额外加一层“是否带 TTL”的判断。
- 判断依据很简单：看你的 Redis 实例里有没有“绝不能丢”的永不过期 key
- 有 → 优先 volatile-lru（或 volatile-lfu）
- 没有 → allkeys-lru 或 allkeys-lfu 更合适
