短生命周期 key 频繁淘汰抖动本质是 volatile-ttl 策略在大量 key 集中过期时触发密集驱逐，导致 cpu 尖峰和延迟；应改用 allkeys-lfu 策略并由业务层实现逻辑过期，避免整点过期抖动。
短生命周期 key 导致的频繁淘汰抖动，本质是 volatile-ttl 或 volatile-lru 策略在大量 key 集中过期时触发密集驱逐，引发 CPU 尖峰和响应延迟。单纯调大 maxmemory 或换 allkeys-lfu 并不能根治——关键得让淘汰行为“不扎堆”、不抢资源。
为什么 volatile-ttl 在短生命周期场景下容易抖动
当业务批量设置 60s、120s 这类整数 TTL（比如 session、临时 token），Redis 的定期删除机制会在每 100ms 扫描一次 expires 字典，一旦发现大量 key 剩余 TTL 接近 0，就会集中触发惰性检查 + 主动驱逐，导致：
– eviction 操作在单个事件循环中堆积
– INFO stats 中 evicted_keys 出现脉冲式增长
– 客户端偶发 READONLY You can't write against a read only replica 或超时（实际是主线程被阻塞）
– redis-cli --latency 显示周期性 20–50ms 延迟尖峰
如何用 LFU 替代 TTL 驱动的淘汰逻辑
LFU 不依赖时间戳，而是靠访问频次做决策，天然规避“整点过期”问题。但直接切 allkeys-lfu 有风险，必须配合业务 TTL 调整：
– 把原本 60s 的 session key 改为永不过期（不设 EXPIRE），改由业务层控制逻辑过期（如 value 中存 {"exp": 1743790260, "data": "..."}）
– 同时配置 maxmemory-policy allkeys-lfu，让 Redis 只按热度淘汰，冷 key 自然沉底
– 必须启用 lfu-log-factor（推荐 10）和 lfu-decay-time（推荐 1）防止早期高频 key 长期霸占内存
– 注意：LFU 计数器只在 key 被访问时更新，所以首次写入后若无读操作，不会进 LFU 排序
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
延长 TTL 的实操边界与陷阱
不是所有 key 都适合“永不过期”，得看数据语义和一致性要求：
– ✅ 适合延长：用户偏好缓存、商品基础信息、配置开关（业务侧加逻辑过期字段即可）
– ❌ 不适合延长：支付订单锁、秒杀库存 token、实时风控凭证（必须强时效，不可妥协）
– ⚠️ 容易踩坑：把 TTL 从 60s 改成 86400s（1天）但没改清理逻辑，导致内存缓慢泄漏；应搭配定时 job 清理逻辑过期 key，或用 SCAN + GET + DEL 异步扫描
– 性能影响：allkeys-lfu 比 volatile-lru 内存开销高约 15%（每个 key 多存 1 个 16bit 计数器），需提前压测
验证是否真正缓解抖动
不能只看平均延迟，要盯住三个指标：
– INFO memory 中 mem_allocator 是否稳定（避免 jemalloc 频繁 rehash）
– INFO stats 中 evicted_keys 是否从脉冲式变为平滑线性增长
– redis-cli --intrinsic-latency 120 运行 2 分钟，确认最大延迟是否压到 5ms 以内
– 如果仍有抖动，大概率是客户端未开启连接池复用，或存在大量 HGETALL / KEYS 类阻塞命令
真正难的不是换策略，而是让业务代码接受“逻辑过期”这个概念——TTL 从 Redis 管，变成应用自己管。这一步跨过去，抖动就从“不可避免”变成“可预测、可削峰”。
