Redis突发批量失效的根本原因是过期与淘汰策略叠加导致响应延迟和内存回收滞后，具体表现为定期删除采样不足、淘汰误杀热key及内存碎片干扰，引发写入卡顿、evicted_keys暴涨、used_memory居高不下。
Redis在突发批量失效时，淘汰队列积压不是“队列满了”的问题，而是过期策略与淘汰策略叠加触发的响应延迟和内存回收滞后——根本原因在于定期删除采样不足 + 淘汰策略误杀热 key + 内存碎片干扰，导致新请求写入卡住、evicted_keys 暴涨、used_memory 居高不下。
为什么定期删除跟不上批量过期节奏
Redis 的定期删除默认每 100ms 执行一次，每次只扫描 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP（硬编码为 20）个 key。如果同一分钟内有上万 key 过期，它靠随机采样根本扫不完，大量已过期 key 滞留在 expires 字典里，继续占用内存，还拖慢后续的淘汰判断。
- 现象：
INFO memory中expired_keys增速远低于实际过期量，mem_fragmentation_ratio> 1.5，但used_memory不降反升 - 关键点：过期 key 没被及时清理，就无法进入淘汰流程；它们只是“逻辑过期”，仍算在内存统计里
- 实操建议：不依赖定期删除兜底，必须从源头控制过期分布——所有批量写入都加随机 TTL 偏移，例如
EXPIRE key 3600 + random.randint(0, 600)
allkeys-lfu + maxmemory-samples 10 能缓解误淘汰
用 volatile-lru 或 volatile-ttl 在批量失效场景下极易雪崩：前者因采样偏差把刚访问的热 key 当冷数据删掉，后者直接优先删马上要过期的 key，加速整批崩溃。
-
allkeys-lfu按访问频次淘汰，天然保护高频 key；哪怕内存紧张，它也不会因“刚写入”或“快过期”就误杀 - 必须同步调高
maxmemory-samples到 10（默认是 5），否则采样太稀疏，LFU 计数器更新不准，热 key 仍可能被漏判 - 禁用
volatile-ttl：它和批量过期是死对头，越想“先删快过期的”，越容易引发连锁失效
UNLINK 替代 DEL，避免主线程阻塞积压
当大量 key 突然过期，业务层若再执行 DEL pattern* 或定时脚本暴力清空，会直接卡死 Redis 单线程——这不是淘汰队列积压，是人为制造阻塞。
- 现象：
slowlog中出现大量 >100ms 的DEL，used_memory_rss骤降但used_memory下降缓慢，说明内存没真正释放 - 正确做法：改用
UNLINK，它立即解除 key 引用，后台线程异步回收内存，不影响主线程响应 - 补充动作：对确认要删的大 key（如
TYPE返回hash/zset且MEMORY USAGE>1MB），优先走UNLINK；别用SCAN+DEL组合，改用SCAN+UNLINK
evicted_keys 暴涨时，必须查 slowlog 和 keyspace_misses
evicted_keys 持续上涨本身不是故障信号，但它和 keyspace_misses 同步飙升，就说明淘汰正在失控——缓存命中率塌方，请求正穿透到 DB。
- 立刻执行：
redis-cli SLOWLOG GET 10，盯del、flushdb、eval类命令是否被误触发 - 同时检查：
INFO stats中keyspace_misses是否突增 5 倍以上，确认是否已有击穿苗头 - 最容易被忽略的一点：
rename-command flushall ""只防手动误操作，防不住代码里写的DEL user:*——得靠应用层 SDK 拦截或 Redis ACL 限制通配符命令
