不能统一配allkeys-lru，因其无差别淘汰所有key，会误删未设ttl的核心数据（如配置、锁、token），且低频访问的关键数据易被挤出，导致配置失效、token无效、缓存穿透等级联故障。
微服务架构下，Redis 通常被多个服务共用，但各服务的数据语义、生命周期、访问模式差异极大——直接套用默认 noeviction 或盲目选 allkeys-lru 很容易导致关键数据被误删、缓存命中率骤降，甚至引发级联故障。
为什么不能统一配 allkeys-lru？
看似“通用”，实则隐患集中：allkeys-lru 会无差别淘汰所有键，包括那些没设过期时间的配置项、分布式锁、幂等 token 等——这些数据本该长期存在，但因访问频次低（比如配置只在启动时读一次），反而最先被踢出。更糟的是，若某服务写入大量临时日志类 key（如 log:20260714:xxx）且未设 TTL，它们会挤占空间，把真正需要缓存的商品详情、用户权限等热 key 挤掉。
- 典型现象：A 服务发现配置突然失效，B 服务提示“token 无效”，C 服务缓存穿透暴增
- 根本原因：LRU 只看“最近访问时间”，不区分数据类型和业务重要性
- 兼容性注意：Redis 4.0+ 才支持近似 LRU 实现；低于该版本的 LRU 更粗糙，误淘汰概率更高
volatile-* 策略才是微服务友好型起点
微服务天然倾向给临时数据显式加 TTL（比如 session 过期 30 分钟、接口响应缓存 5 分钟），而核心元数据、配置、状态类数据往往不设 TTL。此时 volatile-lru、volatile-ttl 或 volatile-lfu 能守住“非过期数据”这条底线。
-
volatile-lru：适合多服务共用但访问模式较规律的场景（如统一 session 存储），优先淘汰长时间没碰过的临时数据 -
volatile-ttl：适合写入大量短命数据的服务（如实时监控指标、临时任务队列），自动清理即将过期的 key，避免手动维护清理逻辑 -
volatile-lfu：需 Redis 4.0+，适合有明确热点分层的场景（如促销页商品缓存 vs 用户浏览历史），比 LRU 更抗“偶发访问干扰” - 风险点：如果某个服务忘了给 key 设 TTL，它就完全免疫淘汰——可能悄悄吃光内存，最终触发
noeviction的 OOM 错误
怎么验证策略是否真起作用？
别只看 config，要盯实际淘汰行为。Redis 不提供实时淘汰日志，但可通过以下方式交叉验证：
- 执行
INFO memory，重点关注evicted_keys字段是否持续增长；若为 0，说明策略未生效（可能是maxmemory没设，或实际内存远低于阈值） - 用
redis-cli --stat观察evicted_keys和used_memory_human是否同步波动 - 对关键服务的 key 命名打标（如
cache:product:xxx、tmp:order:xxx），再用SCAN+TTL抽样检查：预期被淘汰的 key 是否真在变少，且剩余 key 的 TTL 分布是否符合预期 - 警惕“假淘汰”：某些客户端 SDK（如 Lettuce）在连接断开重连时会批量重写 key，造成瞬时内存尖峰，被误判为淘汰压力
最易被忽略的其实是服务间 key 命名隔离——哪怕策略选对了，如果 A 服务的 user:123 和 B 服务的 user:123 共用同一个 key 名，淘汰时根本分不清谁该留谁该走。命名空间（namespace）不是可选项，是淘汰策略能生效的前提。
