Redis LATENCY HISTOGRAM 怎么看命令耗时分布：采样开关、百分位与实例核对

Redis 监控面板上的平均耗时只有 0.4 毫秒，接口却偶尔卡到几十毫秒，这通常不是“平均值算错了”，而是尾部请求被均值盖住了。LATENCY HISTOGRAM 能按命令返回累计延迟分布，适合先确认到底是 GET、SET 还是某个批量命令把高延迟拖出来，再决定是否继续查慢日志或网络。

为什么平均耗时正常，用户仍然会遇到卡顿

假设一分钟内有 99,900 次 GET 只花 0.2 毫秒，另有 100 次因为磁盘抖动或事件循环排队花了 80 毫秒，平均数仍然可能很漂亮。真正影响超时重试和用户感知的，往往是 P95、P99 甚至更靠后的请求。

LATENCY HISTOGRAM 的价值在于把命令调用次数和延迟桶放在同一份结果里。它不告诉你哪一个客户端发起了慢请求，也不保存每条请求的参数；它先回答一个更基础的问题：某类命令的耗时尾部是否真的变厚了。

先确认采样前提和统计时间窗

如果实例没有记录扩展延迟监控，直接查询可能拿不到有用的直方图。先在目标实例上查看配置，再决定是否打开采样：

redis-cli -h 10.0.0.21 -p 6379 CONFIG GET latency-tracking

# 只有确认变更符合实例运维规范时才打开
redis-cli -h 10.0.0.21 -p 6379 CONFIG SET latency-tracking yes

记录这次核对的实例地址、配置值和开始时间。不要把不同实例、不同重启周期或执行过 CONFIG RESETSTAT 后的结果直接拼成一条趋势线；它们的累计调用量并不在同一个统计窗口里。

先查一个命令，再扩展到全量结果

排查线上某个接口时，先过滤与接口路径最相关的 Redis 命令，输出会更容易读：

# 只查看 SET 的累计延迟分布
redis-cli -h 10.0.0.21 -p 6379 LATENCY HISTOGRAM SET

# 再查看当前实例所有已有直方图
redis-cli -h 10.0.0.21 -p 6379 LATENCY HISTOGRAM

返回结果通常包含命令名、calls 以及以微秒为单位的直方图桶。桶是累计计数：某个较大的桶包含落在该延迟范围及更小范围内的调用，不应把相邻桶的数字再次相加。

例如一份结果里，histogram_usec 的 16 桶是 9,968，33 桶是 10,000，可以理解为至少 9,968 次调用不超过 16 微秒、累计到 33 微秒时达到 10,000 次。若出现 +Inf，它承接的是超过约 1 秒的调用，不能把它当成普通的“1 秒桶”。

从累计桶读出可比较的尾部信号

Redis 返回的是累计分布，所以排查时重点看三个关系：calls 是否持续增长、较高延迟桶占总调用量的比例是否变大、+Inf 是否出现或突然增加。

1. 把当前命令名和 calls 保存下来，先确认采样确实覆盖了目标业务流量。
2. 找到接近 P95、P99 的累计桶，用“桶内累计调用数 ÷ calls”做粗略位置判断。
3. 两次采样必须来自同一实例、相近负载和明确的时间窗；若中间重置过统计，重新标记基线。
4. 把命令级信号与应用超时、实例 CPU、网络 RTT 和慢日志放在同一时间线上，不要只凭一个桶判定根因。

这里的百分位是从桶估出来的区间，不是精确到纳秒的单请求排序。桶越粗，估计区间越宽；它适合做方向判断和回归对比，不适合替代带请求 ID 的端到端追踪。

多实例场景：不要把局部结果拼成虚假的全局平均

Redis Cluster 或多副本部署中，每个实例维护自己的命令统计。应用平均延迟正常，可能只是慢请求集中在一个主节点；反过来，某个实例的 P99 变高，也可能是它承载了不同的热点键分布。

建议给每份结果附上实例地址、角色、采样开始时间、结束时间、配置值和当时的业务流量。先按实例分别比较，再在明确调用量口径后做汇总。不要直接平均各节点的 P99，因为各节点的请求数和分布可能完全不同。

常见误区与回滚边界

把直方图当成请求明细

它只有命令级累计统计，没有客户端、键名和参数。想定位单个请求，要结合应用日志或链路追踪。

把桶的数字当成互斥区间

桶是累计分布。较大桶已经包含前面较小桶的调用，不能把每个桶的计数简单相加。

刚执行 RESETSTAT 就拿旧基线比较

CONFIG RESETSTAT 会清理直方图数据。执行后应重新记起点，等一个完整业务窗口，再和新的基线比较。

只看 +Inf，不看调用量

一次低流量测试出现一个超长请求，不等于线上尾延迟已经恶化。先看 calls 和占比，再结合同一时间窗的业务指标。

相关问题

LATENCY HISTOGRAM 从哪个 Redis 版本开始可用？

Redis 官方命令文档标注它从 Redis Open Source 7.0.0 开始提供。连接旧实例时，先用版本和命令能力核对确认，不要把空结果误判成没有慢请求。

为什么查询不到有意义的延迟桶？

先检查 latency-tracking 是否开启、目标实例是否承载了实际流量，以及是否刚执行过统计重置。还要确认查询命令拼写和过滤的命令名与实例实际记录一致。

它和 SLOWLOG 是一回事吗？

不是。直方图提供命令级累计分布，适合观察整体尾部；慢日志保留有限的慢请求记录，适合进一步看单次调用。两者回答的问题不同，可以在同一时间窗互相印证。

要不要一直打开 latency-tracking？

官方文档说明它的内存开销很小，但是否长期打开仍应按实例版本、负载和监控规范评估。生产上更重要的是固定采样窗口和保留配置变更记录，避免数据被无意重置。

把一次查询变成可复核的延迟判断

LATENCY HISTOGRAM 最适合做第一层证据：先按命令看累计桶，再按实例和时间窗比较尾部变化，最后用调用量、慢日志和应用指标确认影响面。这样既不会被漂亮的平均值带偏，也不会因为一个孤立的 +Inf 就贸然改配置。