Redis LATENCY HISTOGRAM 怎样按命令读取延迟分布

排查 Redis 延迟时，我更愿意先把“哪条命令慢”与“整体是不是慢”分开。LATENCY HISTOGRAM 正好提供了按命令读取累计延迟分布的入口：不带命令参数时看全部已有直方图，带上 set、get 等命令时只看指定对象。它不是单次请求日志，而是 Redis 记录的累计桶，因此读取时要同时看调用总数和桶值。

先确认这条命令能看到什么

Redis 官方文档把它定义为命令延迟的累计分布查询。它需要扩展延迟跟踪功能，默认状态通常是开启的。如果返回空结果，先不要急着判断“没有延迟”：可能是目标命令还没有被记录，或者延迟跟踪被关闭。

这个命令属于 @admin、@slow 和 @dangerous ACL 分类。生产环境应使用具备相应权限的观测账号，并把查询频率纳入运维约束。

# 先查看延迟跟踪配置；输出为 yes 才会持续采集命令延迟
CONFIG GET latency-tracking

# 如果确实需要开启采集，再显式设置为 yes
CONFIG SET latency-tracking yes

按命令筛选，先把观测范围缩小

不带参数的查询适合做一次全局盘点，但命令多时返回内容会变长。真正排查一个接口的缓存读写时，通常先指定相关命令；需要比较读写路径，再一次传入多个命令。

# 全量读取当前已有的命令延迟直方图
LATENCY HISTOGRAM

# 只读取 SET 的累计延迟分布
LATENCY HISTOGRAM set

# 同时比较 GET、SET 和 HGET，命令名之间用空格分隔
LATENCY HISTOGRAM get set hget

筛选参数是命令名，不是业务接口名，也不会替你按客户端、数据库编号或调用方拆分。若同一条 Redis 命令承载多个业务场景，这个直方图只能说明命令层面的分布，不能单独证明某个接口的耗时。

读懂 calls 与累计时间桶

典型返回会给出命令名、calls 和 histogram_usec。calls 是被统计的调用总数；时间桶的键表示延迟阈值，值表示累计落在该阈值以内的调用数。例如 2 微秒桶的值包含 1 微秒桶以内的调用，不能把两个值相加。

官方示例中的桶大致按 1、2、4、8、16 微秒递增，后一个桶覆盖前一个桶两倍的范围。空桶会被省略，所以返回结果中的键不一定连续；这并不等于数据损坏。

把一次读取变成可复查的检查清单

我通常按下面的顺序记录结果：先记 Redis 版本与 latency-tracking 状态，再记查询命令和采样时间；随后把 calls 与应用侧请求量对照，最后关注高延迟桶和 +Inf 是否明显增长。这样能避免把一段很久以前的累计数据，误当成刚发布版本的即时表现。

如果需要建立新的观察窗口，可以清除延迟统计：

# 清除统计后重新采集；这会影响当前实例上的统计数据
CONFIG RESETSTAT

# 重新按目标命令读取新窗口中的累计分布
LATENCY HISTOGRAM get set

CONFIG RESETSTAT 是有影响范围的管理操作，不应在没有记录旧窗口的情况下直接执行。更稳妥的做法是先保存一次全量结果，再重置，并在应用侧同时记录请求数、错误率和端到端耗时。

常见问题

为什么 LATENCY HISTOGRAM 没有返回我想看的命令？

先确认该命令在当前实例上实际执行过，并检查延迟跟踪是否开启。命令名还要与 Redis 命令匹配，不能填业务接口名。

时间桶的数字能直接当作 P99 吗？

不能直接当作精确 P99。它是离散的累计桶，最多只能据此判断某个延迟阈值以内的累计数量；要做精确分位数，应结合更细粒度的应用指标或外部观测。

为什么调用总数和业务请求数对不上？

统计窗口、连接层重试、管道批量调用以及应用侧请求与 Redis 命令的一对多关系，都可能造成差异。先统一时间窗口和命令范围，再比较数值。