Redis Latency Monitor 怎么定位阻塞事件

Redis 出现偶发慢请求时，先不要直接把所有问题归因于网络。Redis 的延迟监控会按事件类型记录超过阈值的尖峰，例如普通命令执行、fork、AOF 写入和淘汰周期。定位阻塞事件的顺序是：先设置合理阈值，再看 LATENCY LATEST 识别事件，最后用历史和诊断命令确认时间形态。

官方文档：https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/latency-monitor/

先用业务阈值打开延迟监控

Redis 官方文档说明，只有耗时超过配置阈值的事件才会被记录；什么算高延迟取决于业务。比如接口要求 Redis 操作尽量低于 100 毫秒，可以先把阈值设为 100，而不是照搬一个与业务无关的固定数字。

# 按业务可接受的最大延迟记录尖峰
redis-cli CONFIG SET latency-monitor-threshold 100

# 查看当前阈值，确认配置确实已生效
redis-cli CONFIG GET latency-monitor-threshold

这里的阈值单位是毫秒。它不是“客户端请求超时”开关，而是 Redis 服务端事件采样条件。若阈值过低，历史记录会被噪声填满；过高则可能漏掉对当前接口已经有影响的尖峰。

用 LATENCY LATEST 先锁定阻塞事件

阈值生效后，第一条定位命令应看最近样本：

# 列出所有事件最近一次采样，先判断阻塞来自哪一类路径
redis-cli LATENCY LATEST

# 让 Redis 根据已记录的事件给出人类可读的诊断提示
redis-cli LATENCY DOCTOR

LATENCY LATEST 的结果按事件名提供最近样本，常见事件包括 command、fast-command、fork、aof-write、expire-cycle 和 eviction-cycle。判断时先记下事件名、最近时间和延迟值，再决定下一步，不要把 command 直接等同于某一条具体业务命令。

LATENCY DOCTOR 的文字提示适合做初筛，但它是根据监控样本给出的分析，不替代命令审计、系统监控和业务时间线。

用 HISTORY 和 GRAPH 判断尖峰是否持续

确定事件名后，再把它代入历史查询。例如最近样本显示 command，就查看该事件的时间序列：

# 查看 command 事件的时间序列，判断是单次尖峰还是连续抖动
redis-cli LATENCY HISTORY command

# 用 ASCII 图快速观察尖峰分布
redis-cli LATENCY GRAPH command

历史记录能帮助你把一次慢请求和持续性阻塞分开：单个高点更适合关联某次重操作、重写或系统抖动；连续高点则应继续看是否有稳定触发源。官方文档说明每个事件的时间序列保留有限数量的样本，同一秒内的尖峰会合并为该秒的最大延迟，所以它适合定位形态，不应被当作完整的请求日志。

把事件结果落到可验证的排查动作

如果是 command，回到慢命令记录和参数规模，重点找 O(N) 操作或一次处理过多元素的调用；如果是 fork，把尖峰时间与 RDB 或 AOF 重写时间对齐；如果是 aof-write，关联磁盘延迟和 fsync 配置；如果是 expire-cycle 或 eviction-cycle，检查过期、淘汰与内存压力。每个方向都应留下“事件时间—业务现象—外部指标”的三点证据。

排查完成后，可以用 LATENCY RESET 清理已确认的事件记录，再观察新的窗口。清理前应先保存需要对比的时间和数值，因为 reset 会改变后续观察的基线。

# 仅在已记录结果并准备开启新观察窗口时清理 command 数据
redis-cli LATENCY RESET command

# 查看所有事件的当前记录，确认新窗口是否重新出现尖峰
redis-cli LATENCY LATEST

Redis Latency Monitor 常见问题

latency-monitor-threshold 设置为多少合适？

从业务能接受的 Redis 服务端延迟倒推，例如接口希望 Redis 操作不超过 100 毫秒，可以先设为 100，再根据噪声和漏报情况调整。它不是通用性能基准。

看到 command 事件就能知道是哪条命令慢吗？

不能。它说明被监控的命令执行路径出现了超过阈值的尖峰，还需要结合慢命令记录、调用参数和同一时间的业务日志确认具体调用。

LATENCY HISTORY 为什么不能替代完整日志？

它是按事件聚合的时间序列，同一秒的多个尖峰会合并，且只保留有限历史样本。它适合判断时间形态，不适合逐请求还原。

总结

Redis Latency Monitor 的定位关键是先分事件、再看时间形态、最后关联外部证据。用合理阈值打开监控，借助 LATENCY LATEST 和 LATENCY DOCTOR 找方向，再用 HISTORY、GRAPH 判断是否持续，才能把“Redis 偶发变慢”落成具体的命令、持久化或内存排查任务。