淘汰引发的延迟尖峰是什么
内存达到 maxmemory 后，淘汰动作会插进命令执行路径：主线程在返回结果前要先找出可淘汰的键并释放。链式淘汰（一次内存增长触发连续删除）或多个键同时被淘汰时，单次请求的延迟就被放大，表现成与淘汰速率同步出现的延迟毛刺。
基本信息
| 触发条件 | 内存达到 maxmemory 且淘汰策略不是 noeviction |
|---|---|
| 观测指标 | evicted_keys、LATENCY 的 eviction-cycle 事件 |
| 放大因素 | 大键淘汰、链式淘汰、同步释放内存 |
| 缓解手段 | 提高容量余量、调整策略、开启异步释放 |
| 关联配置 | maxmemory-policy、maxmemory-samples、lazyfree-lazy-eviction |
典型使用场景
- 延迟毛刺排查：把淘汰速率曲线与 P99 时间轴对齐，确认是否存在相关性
- 容量长期贴线运行：反复出现周期性抖动时，先看淘汰速率是否持续为正
- 大键治理：单个大容器的释放开销远大于小键，淘汰大键时尤其明显
- 策略评审：LRU 与 LFU 的采样开销和访问分布敏感度不同，选型要看业务
- 压测验证：保留与摘除淘汰条件各跑一轮，对比两次的延迟分布
证据采集
证据采集
redis-cli INFO stats | grep -E 'evicted_keys' # 累计淘汰键数，取差值看速率
redis-cli INFO memory | grep -E 'used_memory:|maxmemory:' # 是否长期贴线
redis-cli CONFIG GET maxmemory-policy # 淘汰策略
redis-cli CONFIG GET maxmemory-samples # 采样个数影响精度与开销
redis-cli LATENCY LATEST # 是否出现 eviction-cycle 事件
redis-cli CONFIG SET lazyfree-lazy-eviction yes # 淘汰改为异步释放内存延迟证据对照
| 信号 | 含义 | 指向 |
|---|---|---|
| evicted_keys 与 P99 同步上升 | 淘汰直接放大请求延迟 | 容量或策略问题 |
| LATENCY 出现 eviction-cycle | 淘汰循环本身耗时超阈值 | 内存侧需要介入 |
| 抖动周期固定 | 与定时任务节奏相关 | 对照 hz 与持久化周期 |
| 只有大键被淘汰时变慢 | 单键释放开销大 | 先拆分大键 |
策略差异要清楚：noeviction 达到上限直接报错；allkeys-* 在全体键里找受害者；volatile-* 只在设了过期时间的键里找，找不到可淘汰键时同样报错。
延迟排查清单里要包含内存侧指标，两边的曲线往往互相印证；只看命令层会漏掉淘汰这条证据链。