会，而且非常容易——只要策略选错或配置不匹配，热点 key 就大概率被误删；volatile-lru/volatile-ttl 忽略访问频次只看 TTL，易批量淘汰热 key；allkeys-lfu 依赖采样精度，需调高 maxmemory-samples；noeviction 是逻辑过期方案的底线。
会，而且非常容易——不是“可能”，而是只要策略选错或配置不匹配，热点 key 就大概率被误删。
volatile-lru / volatile-ttl 为什么对热点数据最危险
这两个策略只看“有没有设 TTL”，不看“访问频次”或“业务重要性”。哪怕你把 user:1001 设了 7 天过期，只要它在内存压力下被采样到，就会按 LRU 或 TTL 倒序被踢掉。
- 典型陷阱：上线时给所有 key 统一加
EXPIRE key 86400，结果凌晨流量低谷期 Redis 扫描到一批刚写入的热 key（比如登录态、商品详情），它们因“最近没访问”或“剩余 TTL 最短”被批量淘汰 -
volatile-ttl更隐蔽：它优先删“马上过期”的 key，但如果你用定时任务每小时刷新一次缓存，并统一设 TTL=3600，那整点一过，所有 key 几乎同时进入“倒计时最后几秒”，触发集中淘汰 - 监控信号很明确：
evicted_keys持续上涨 +keyspace_hits突降 + 数据库慢查询集中在几个固定 key 上，基本可断定是 volatile 策略误杀
allkeys-lfu 真的能保热点吗？要看 maxmemory-samples
allkeys-lfu 是目前最接近“保热放冷”的策略，但它依赖采样精度。默认 maxmemory-samples 5 意味着每次只随机看 5 个 key，如果这 5 个碰巧全是新写入的冷数据，LFU 计数器再高也没用——热 key 就这么被跳过了。
- 必须调高采样数：
config set maxmemory-samples 10或更高（实测 10–20 是性价比拐点） - 注意 LFU 衰减：
lfu-log-factor和lfu-decay-time影响计数器衰减速度，高频但间歇性访问的 key（如每日报表）可能因衰减被误判为冷数据 - 别信“LFU 绝对安全”：冷启动时所有 key 计数器为 0，首次内存压力下仍可能随机淘汰；突发流量涌入时，新 key 计数器来不及积累，老热 key 反而更稳
noeviction 不是万能解药，但它是“永不过期”策略的底线
想用“逻辑过期+后台刷新”保热点？noeviction 是唯一真正兼容的选项。其他任何策略都会在内存满时强行删 key，直接破坏你设计的保活机制。
-
allkeys-lru看起来温和，但它会淘汰“最久未访问”的 key——而你的后台刷新线程可能每 5 分钟才扫一遍，中间空档期的热 key 就是 LRU 的理想目标 -
PERSIST只能救单个 key，不能救策略本身；你给hot_key执行PERSIST后，它确实不参与 volatile 类淘汰，但若策略是allkeys-lru，它照常被算进淘汰池 - 切策略前必须验证：
redis-cli --scan --pattern "hot_*" | xargs -n 100 redis-cli ttl，确保所有热点 key 的 TTL 返回-1，否则noeviction也救不了你
真正难的不是选哪个策略，而是让策略和你的数据生命周期对齐：TTL 加偏移、LFU 调采样、noeviction 配逻辑过期——三者缺一不可。线上改策略前，先压测 10 分钟，盯着 evicted_keys 和 keyspace_misses 曲线，比看文档管用十倍。
