maxmemory 必须先设置，否则所有淘汰策略无效；noeviction 在缓存场景下危险，因只拒写不驱逐，易致上游异常雪崩；volatile-lru 依赖过期键比例，allkeys-lru 更通用；volatile-ttl 适用于短周期任务状态缓存；LFU 有CPU开销，需压测验证。
maxmemory 必须先设，否则所有淘汰策略都无效——这是最常被忽略的前提。
为什么 noeviction 在缓存场景下反而危险？
它不删数据，只拒写。但缓存系统本就依赖“写入驱逐旧值”，一旦触发，SET、HSET 等命令直接返回 OOM command not allowed when used memory > 'maxmemory' 错误，上游服务可能抛异常或降级失败。
适用场景其实很窄：仅限纯只读+可重建的元数据缓存，或金融类强一致性写库（此时 Redis 仅作旁路日志暂存）。普通业务缓存用它，等于把内存压力转嫁给应用层重试逻辑，极易雪崩。
- 检查是否已启用：
CONFIG GET maxmemory返回"0"就代表没开上限，淘汰策略形同虚设 -
noeviction下evicted_keys指标恒为 0，但rejected_connections或客户端报错数会飙升 - 若必须保数据，优先考虑分库：热数据用
allkeys-lru，冷数据单独实例配noeviction
volatile-lru 和 allkeys-lru 到底该选哪个？
关键看你的过期键占比和数据分层逻辑。如果大量 key 都没设 EXPIRE（比如用户 session 用 SETEX，但配置中心数据用 SET 永不过期），volatile-lru 可能根本找不到可淘汰对象，最终退化成 noeviction。
而 allkeys-lru 虽然更“激进”，但它对无过期时间的 key 同样有效——只要访问频次低，就会被抽样淘汰。这对通用缓存更友好。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 查当前过期键比例：
INFO keyspace中看各 db 的expires字段，若keys远大于expires，volatile-*类策略基本失效 -
maxmemory-samples默认是 5，调高到 10～15 可提升 LRU 近似精度，但单次淘汰耗时增加，需压测验证延迟毛刺 - 注意：
LRU是近似算法，靠robj.lru字段的 24 位时间戳截断值判断，不是精确访问顺序
volatile-ttl 适合什么真实业务？
它不看访问频次，只比谁快过期。典型用于短周期任务状态缓存：比如秒杀库存预扣减的临时锁（SET lock:order:123 "1" EX 10），或 API 限流窗口计数器（INCRBY counter:ip:192.168.1.1 1 + EXPIRE）。这类数据天然具备“越早设过期，越该先删”的语义。
但一旦混入长 TTL 或永不过期 key，volatile-ttl 就完全失效——它只在带 EXPIRE 标记的 key 中找最小 TTL。
- 监控
evicted_keys增速的同时，务必对比expired_keys：若后者远高于前者，说明淘汰主要靠被动过期，volatile-ttl实际未起效 - 不要把它当“智能清理”，它只是 TTL 排序器。想保热点，得靠
LFU；想保时间敏感性，才用它 - Redis 7.0+ 支持
maxmemory-eviction-step控制单次淘汰数量，避免大 key 集中释放导致延迟抖动
LFU 策略的隐含成本你测过吗？
volatile-lfu 和 allkeys-lfu 要维护每个 key 的访问频次计数器，每次 GET 都要更新。高频读场景下，CPU 使用率可能比 LRU 高 15%～20%，尤其在小 key 大量并发读时。
它的优势在于识别“稳定中频访问”数据（比如每日固定时段查询的报表缓存），但对突发流量不敏感——计数器衰减周期默认是 100 万次访问或 1 分钟（由 lfu-decay-time 控制），新热 key 需要时间积累热度。
- 启用前先开
INFO stats看instantaneous_ops_per_sec峰值，若 > 5w QPS，建议压测 LFU 开销 -
lfu-log-factor越大，频次区分度越高（10 以上才能明显区分 100 次 vs 1000 次访问），但计数器溢出风险上升 - LFU 不是银弹：如果业务里 80% 的读集中在 20% 的 key 上，
allkeys-lru实际命中率可能更高，因为 LRU 对“最近一次访问”更敏感
volatile-ttl，商品详情用 allkeys-lru，配置中心用 noeviction 单独实例。混在一个实例里硬套一种策略，迟早踩坑。 
