Redis TDIGEST.QUANTILE怎么查询多个分位点

如果你已经把延迟、耗时或其他数值流写进 Redis t-digest，查询 P50、P90、P99 不需要发三条命令。TDIGEST.QUANTILE 的语法本身允许在 key 后连续传入多个分位点，返回数组会按照这些分位点的输入顺序排列。这里的结果是 t-digest 的浮点估算；只有 0 和 1 这两个边界对应最小、最大观测值。

官方地址：https://redis.io/docs/latest/commands/tdigest.quantile/

一条命令查询多个分位点

把分位点写成 0 到 1 之间的小数：P50 是 0.5，P90 是 0.9，P99 是 0.99。命令的通用形态是 TDIGEST.QUANTILE key quantile [quantile ...]，方括号表示后面可以继续添加更多分位点。

# 先创建 sketch 并写入一组示例观测值
redis-cli TDIGEST.CREATE latency COMPRESSION 1000
redis-cli TDIGEST.ADD latency 12 18 21 25 31 36 42 55 80 120

# 一次查询 P50、P90 和 P99，参数顺序就是结果的对应顺序
redis-cli TDIGEST.QUANTILE latency 0.50 0.90 0.99

这几条命令只是文章中的调用示例。真正使用时，key 必须已经是存在的 t-digest sketch；不要把普通字符串、列表或哈希 key 当成它来查询。

返回数组要按输入位置读取

假设请求是 0.50 0.90 0.99，返回数组的第一个元素就是 P50 估算值，第二个是 P90，第三个是 P99。这里应当使用“位置对齐”，而不是拿返回值重新排序后再猜它们对应哪个分位点。

# 用清楚的变量名记录输入位置，避免批量查询后错配指标
quantiles="0.50 0.90 0.99"

# 返回数组的第 1、2、3 项分别对应 P50、P90、P99
redis-cli TDIGEST.QUANTILE latency 0.50 0.90 0.99

如果应用层需要 JSON 或监控标签，建议在发送命令前固定一张“分位点—指标名”映射表，例如 0.50 → p50、0.90 → p90、0.99 → p99，收到结果后按数组下标写入对应字段。这样即使以后增加 P95，也只是追加一个明确位置，不会破坏原有字段含义。

不要把估算分位点当成精确排序结果

t-digest 的价值是用紧凑 sketch 估算数据流的分位点，所以中间分位点返回的是浮点估计，不是把所有样本完整排序后得到的精确索引值。官方命令文档给出的边界语义很明确：

• 0 对应最小观测值；
• 1 对应最大观测值；
• 0 和 1 之间的输入返回对应分数位置的浮点估算；
• 同一条命令可以混合多个分位点，返回数量与输入数量一致。

空 sketch 和错误输入怎么处理

如果 sketch 存在但还没有观测值，官方返回信息是所有分位点得到 nan。这和“某个真实指标恰好等于 NaN”不是一回事，应用层可以把它当作暂时没有样本来处理。

# 创建一个没有 ADD 数据的空 sketch
redis-cli TDIGEST.CREATE empty_latency

# 空 sketch 的查询结果按官方语义会是 nan
redis-cli TDIGEST.QUANTILE empty_latency 0.50 0.99

# 参数范围必须包含在 0 到 1；非法输入应作为错误处理
redis-cli TDIGEST.QUANTILE latency 1.20

key 不存在、key 类型不正确、分位点无法解析或参数数量不正确时，Redis 返回错误，而不是正常的估算数组。生产代码应区分“空 sketch 的 nan”和“命令失败”，不要把二者都转换成 0。

常见问题

可以一次查询 P50、P95、P99 吗？

可以。把 0.50 0.95 0.99 作为同一条 TDIGEST.QUANTILE 命令的连续参数传入，按返回数组位置分别读取。

中间分位点为什么不是精确值？

因为 t-digest 是用于分位点估算的概率数据结构，中间位置由 sketch 给出浮点估计；如果业务必须得到精确排序结果，应改用能保留完整样本的方案。

查询结果全部是 nan 怎么办？

先确认 key 指向的是正确的 t-digest sketch，并检查是否已经成功写入观测值。空 sketch 按官方语义会对所有请求分位点返回 nan。