延迟尖刺排查清单
延迟尖刺几乎从不是单一原因，而是「定义影响面 → Redis 内部事件 → 慢命令 → 持久化与内存 → 系统与网络 → 修复回归」这条链路中的某一环。清单的作用是保证每一层都留下证据，避免只盯着最熟悉的那一层反复打转。
排查顺序
| 第一步 | 定义影响面：哪些命令、哪个时间段、多少请求受影响 |
|---|---|
| 第二步 | LATENCY LATEST 与 HISTORY 看事件类别、峰值与时间分布 |
| 第三步 | SLOWLOG 看具体命令、耗时与来源客户端 |
| 第四步 | INFO persistence / clients / memory 看后台任务、连接与内存水位 |
| 第五步 | 系统层：CPU 抢占、网卡丢包、磁盘 fsync、虚拟化与容器资源限制 |
| 第六步 | 修复后盯同一指标确认回稳，并记录时间线 |
现象与来源对照
| 现象 | 常见来源 | 下一步动作 |
|---|---|---|
| 周期性秒级尖刺 | fork 快照、AOF 重写等后台任务 | 查 INFO persistence 的最近保存与重写耗时 |
| 个别命令超时 | 大键全量操作：KEYS、HGETALL、SORT、大集合聚合 | 在慢日志 args 里确认命令形状与键规模 |
| 所有命令整体变慢 | 内存换页、CPU 被其他进程抢占 | 查系统 swap 使用与进程 CPU 争抢 |
| 只有部分客户端慢 | 网络路径、客户端自身阻塞 | 在客户端侧埋点做端到端对照 |
| 大量连接超时或报错 | 超过 maxclients 被拒、输出缓冲区超限 | 查 rejected_connections、blocked_clients 与 client list |
取证命令
取证命令
redis-cli LATENCY LATEST # 每类事件的最新值与历史最大值
redis-cli LATENCY HISTORY command # 某类事件的时间序列
redis-cli LATENCY RESET # 清空事件统计后重新观察
redis-cli SLOWLOG GET 10 # 具体慢命令与来源
redis-cli INFO persistence # 后台保存与重写状态
redis-cli INFO clients # 连接数、阻塞客户端与缓冲
redis-cli --latency-history -i 5 # 客户端视角每 5 秒采样一次典型使用场景
- 上线后收到零星超时告警，需要快速分层定位是命令、后台任务还是系统资源
- 周期性尖刺：确认是否与快照、重写等后台动作同频
- 扩容决策前的基线整理：先把存量延迟来源摸清再谈加机器
- 值班交接：用同一清单产出结论，避免换人就重新排查
- 故障复盘：回放时间线，确认每层证据是否齐全
LATENCY 只覆盖部分事件类别，常见的有 command、fork、expire-cycle、aof-fsync-always 等；LATENCY LATEST 里的 max 是历史峰值，配合 HISTORY 看分布才有判读价值。
排查过程本身要留痕：什么时间、看到哪条证据、做了什么动作、指标如何变化。没有时间线的排查结论无法复用。