大促时改maxmemory-policy基本无效，因缓存击穿主因是批量key集中过期（如统一EXPIRE 3600），此时内存远未达maxmemory阈值，淘汰策略根本不触发；真正关键在于打散过期时间、热点key永不过期+主动刷新、业务层降级控制。
电商大促期间不能靠临时改 maxmemory-policy 来扛流量，它只是内存满后的兜底动作，不是防雪崩或抗突发的手段。
为什么大促时改淘汰策略基本没用
大促压测和真实流量中，缓存失效高峰往往发生在活动开始前 1 分钟——大量 key 同时自然过期（比如统一设了 EXPIRE 3600），此时 Redis 内存可能才用到 40%，maxmemory 根本没触达，maxmemory-policy 完全不触发。而你看到的“缓存击穿+数据库被打挂”，根源就在这批集中过期，跟淘汰策略无关。
-
volatile-ttl在这种场景下反而最危险：所有 key TTL 相同，它会把同一秒到期的几百个热 key 批量踢掉 -
allkeys-random或volatile-random无法保证不误删商品详情、库存锁这类关键 key - 即使切到
allkeys-lru，如果预热数据写入后长期无访问（比如首页 banner 缓存写完就没人点），LRU 链表会把它当冷数据优先淘汰
真正该在大促前做的三件事
淘汰策略不是调参对象，而是验证基准。重点应放在让淘汰行为「可预期、低干扰、不放大故障」：
- 提前 48 小时将
maxmemory设为物理内存的 60%～70%，留出空间给 fork、AOF rewrite、复制积压缓冲区；不要设成 90% 甚至等于总内存 - 确认
lazyfree-lazy-eviction是no（默认值）：大促期间必须同步完成淘汰，避免异步任务堆积导致响应延迟毛刺 - 用
redis-cli --memstat-stats扫描 key 类型分布，重点检查 hash / zset 是否存在单 key > 1MB 的情况；这类大 key 会显著拖慢 LRU 抽样和淘汰速度
大促中监控哪些指标比看策略更重要
策略本身不会报警，但它的副作用会体现在指标里。盯紧这几个字段，比反复纠结该用 LRU 还是 LFU 实用得多：
-
evicted_keys：每分钟突增 > 500 表示淘汰已成常态，不是好信号；持续增长说明maxmemory设低了或有死 key 没清理 -
keyspace_hits/keyspace_misses：命中率跌破 85% 且misses暴涨，大概率是批量过期或淘汰误伤，不是策略问题，是过期时间设计问题 -
mem_fragmentation_ratio> 1.8：jemalloc 碎片严重，会导致used_memory_rss远高于used_memory，看似内存还有余量，实则物理内存快爆了
复杂点在于：你没法靠改一个配置解决大促缓存压力。真正起作用的是过期时间打散（比如加随机偏移）、热点 key 永不过期 + 主动刷新、以及降级开关控制缓存穿透阈值——这些都不在 redis.conf 里，而在你的业务代码和发布流程中。
