allkeys-lfu更抗突发写入冲击，因其基于带衰减的访问频次淘汰，避免新key单次访问即“续命”而挤占热key；allkeys-lru则依赖最近访问时间，易误淘汰稍早访问的高频key。
突发流量下，allkeys-lfu 通常是比 allkeys-lru 更稳妥的选择，但前提是 Redis 版本 ≥ 4.0，且业务数据存在明显长尾访问特征。
为什么 allkeys-lfu 比 allkeys-lru 更抗突发写入冲击
突发流量常伴随大量一次性或低频访问的 key（如临时会话、活动页埋点、短时爬虫请求），allkeys-lru 会把这些新 key 的访问时间记为“最新”，导致原本高频但稍早访问的热 key 被误淘汰；而 allkeys-lfu 基于访问频次计数，能更稳定识别真正高热度的数据。
常见错误现象：allkeys-lru 在秒杀预热阶段把商品详情缓存挤掉，后续真实请求全部穿透到 DB。
-
allkeys-lfu的计数器带衰减机制（默认每分钟衰减一次），不会被单次突发冲垮 - 可通过
CONFIG SET lfu-log-factor 10提高计数精度（值越大，对低频访问越敏感） - 注意：若突发流量全是写入（无读），LFU 计数不生效，此时策略退化为随机采样淘汰
什么时候该用 volatile-ttl 替代全量策略
当突发流量集中在有明确生命周期的临时数据上（如短信验证码、登录 Token、活动倒计时），且这些 key 都设置了 TTL，则 volatile-ttl 能优先清掉“马上要过期”的键，避免误伤长期有效的业务缓存。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
使用场景：SET verify:138****1234 "abcde" EX 120 类型的 key 占比超过 60%，且 TTL 分布集中（比如 60–180 秒）
- 必须确保核心数据（如用户信息、商品元数据）不设 TTL，否则会被卷入淘汰池
- 如果部分临时 key 设置了过长 TTL（如 7 天），
volatile-ttl就失去意义——它只看“剩余时间最短”，不是“到期时间最早” - 无法应对无 TTL 的突发写入（比如日志类
LPUSH log:20260903），此时直接触发noeviction报错
maxmemory-samples 调整对突发流量的实际影响
Redis 默认只从所有候选 key 中随机采样 5 个做淘汰决策。在突发写入导致内存快速打满时，这个采样数太小，容易选错淘汰目标。
实操建议：
- 将
maxmemory-samples从默认 5 提升到 10 或 15（CONFIG SET maxmemory-samples 10） - 但不要盲目设到 30+：采样越多，每次淘汰耗时越长，可能拖慢主线程响应
- 验证方式：观察 INFO memory 输出中的
evicted_keys增速与expired_keys比例——若前者远高于后者，说明淘汰逻辑正在主动清理，而非靠过期被动释放
真正容易被忽略的是：淘汰策略只在“写入命令执行前”检查内存，而像 HMSET、LPUSH 这类批量操作，可能因单次申请内存过大直接触发 noeviction 错误，和策略本身无关。这时候得配合客户端做分片写入或预估内存占用。
