LATENCY HISTORY 是什么
LATENCY HISTORY 事件名 返回该类延迟事件的历史尖峰序列，每条包含事件类别、发生时间戳和持续毫秒数。它是 Redis 内置延迟监控（由 latency-monitor-threshold 开启）的输出之一，用来判断延迟问题是零散偶发还是周期性复发。
基本信息
| 命令 | LATENCY HISTORY event |
|---|---|
| 常见事件 | command、fork、expire-cycle、aof-fsync-always 等 |
| 前置条件 | latency-monitor-threshold 大于 0（默认 0 表示不监控） |
| 同族命令 | LATENCY LATEST / RESET / DOCTOR / HELP |
| 单位 | 阈值与记录值均为毫秒 |
典型使用场景
- 判断毛刺是否周期性：把时间戳与定时任务窗口对齐
- 确认 fork 与持久化对延迟的影响程度
- 修复前后对比同类事件的峰值变化
- 为复盘提供按时间排序的客观证据
- 与监控系统的告警时间交叉验证，排除误报
开启监控与取序列
开启监控与取序列
redis-cli CONFIG GET latency-monitor-threshold # 默认 0：不记录任何事件
redis-cli CONFIG SET latency-monitor-threshold 50 # 单位毫秒，超过才记录
redis-cli LATENCY LATEST # 各事件最近一次尖峰
redis-cli LATENCY HISTORY command # 该事件的历史序列
redis-cli LATENCY HISTORY fork
redis-cli LATENCY RESET command # 分析完再清理该类事件输出逐列读法
| 字段 | 含义 | 怎么读 |
|---|---|---|
| event | 事件类别 | 不同类别指向不同根因（命令、fork、过期等） |
| timestamp | 事件发生的绝对时间（秒） | 与业务窗口、定时任务、发布记录对照 |
| duration | 持续时间（毫秒） | 明显高于设定阈值时才值得处理 |
| 序列条数 | 保留的尖峰数量有限 | 长期观察必须靠外部采集，不能只看内置序列 |
记录的是「超过阈值」的尖峰，不是全量采样：没有记录不等于没有慢请求，只说明没有超过阈值。
fork 与 AOF fsync 类事件和持久化配置强相关，分析时要同时看持久化相关配置与 INFO persistence。
阈值设得过低会让记录被频繁刷写、样本失去代表性；先按业务可接受延迟的倍数设定，再逐步收紧。
拿到序列后的分析步骤
- 先看时间戳分布：是均匀散落还是集中在固定时刻
- 再按事件类别分组，判断根因属于命令、持久化还是会话操作
- 把尖峰时刻与定时任务、备份窗口、发布记录对齐
- 对可疑窗口补充 LATENCY DOCTOR 与 INFO 的证据链
LATENCY DOCTOR 把原始事件翻译成结论式建议，适合在看完 HISTORY 之后使用：一个给时间线，一个给解读。