Redis CMS.INFO 怎样读取计数草图的宽度与深度

Redis 的 CMS.INFO 用来读取 Count-Min Sketch 的结构信息。最小用法是把已经初始化的草图 key 传给它：返回结果按字段和值成对出现，其中 width 是每一行的桶数，depth 是哈希行数，count 是写入草图的累计增量。

因此，想回答“宽度和深度是多少”，直接看 CMS.INFO key 的前四个返回项即可；想判断计数是否可信，还要把这些参数和 CMS 的碰撞、高估特性一起看，不能只盯着一个数字。

官方文档：https://redis.io/docs/latest/commands/cms.info/

先用 CMS.INFO 读取 width、depth、count；其中 width 和 depth 描述草图容量与哈希行数，count 只代表累计增量，不代表某个元素的频次。

width、depth 和 count 分别表示什么

Count-Min Sketch 用多行计数桶保存数据流中的频次估计。每个元素会经过多组哈希函数，落到不同的行和桶里。width 决定每行有多少桶，depth 决定有多少行、也可理解为使用多少组独立哈希位置。

这三个字段的职责可以先按下面的表格区分：

先创建一个可以查询的 Count-Min Sketch

CMS.INFO 不能替代初始化命令。测试一个新 key 时，可以先用 CMS.INITBYPROB 按误差率和置信度初始化，再写入几类事件。下面的数字只用于组成可重复阅读的命令示例：

# 以 0.1% 误差率和 99.8% 置信度初始化草图
redis-cli CMS.INITBYPROB metrics:api 0.001 0.002

# 给两个事件累加计数，第二个参数是元素，第三个参数是增量
redis-cli CMS.INCRBY metrics:api login 120 timeout 7

这里的 0.001 是误差率参数，0.002 是允许的误差概率。Redis 会根据它们计算合适的结构尺寸；如果业务需要直接指定尺寸，也可以使用 CMS.INITBYDIM，但这篇文章只用 CMS.INFO 负责读取结果。

用 CMS.INFO 读取 width 与 depth

初始化并写入数据后，执行下面的命令：

# 读取草图的结构参数与累计增量
redis-cli CMS.INFO metrics:api

返回值是 Redis 协议中的扁平键值序列，阅读时按“字段、值”两项一组解析。官方示例的结构类似这样：

1) width
2) (integer) 2000
3) depth
4) (integer) 9
5) count
6) (integer) 127

上例可以读成：width=2000、depth=9、count=127。其中 width 和 depth 是草图的结构属性；count 会随着后续 CMS.INCRBY 的正负增量变化，所以它更适合用来判断“这张草图累计接收了多少计数”，不适合用来回答“login 出现了多少次”。

怎样把 CMS.INFO 的结果和 CMS.QUERY 对照起来

要查看某个元素的估计频次，应使用 CMS.QUERY。它和 CMS.INFO 的分工不同：前者读元素估计值，后者读草图元数据。

# 查询两个元素的估计频次，返回顺序与参数顺序一致
redis-cli CMS.QUERY metrics:api login timeout

# 再看草图的总累计增量，不能把它当成 login 的值
redis-cli CMS.INFO metrics:api

Count-Min Sketch 为节省空间，允许不同元素经过哈希后落入同一个桶。查询一个元素时，Redis 会综合多行计数，碰撞通常会让估计值偏高，而不是凭空给出一个精确的全量统计。因此，CMS.QUERY 的结果适合识别高频项、做近似排序或阈值判断；低频值应结合误差率谨慎解释。

遇到读数异常时按四步检查

1. 先确认 key。 CMS.INFO 查询的是具体草图 key。把业务前缀、日期后缀或环境名写错，读到的可能是另一张草图。
2. 再确认初始化方式。 CMS.INITBYPROB 由误差目标推导尺寸，CMS.INITBYDIM 则直接指定 width 和 depth，两者的排查思路不同。
3. 把 count 当作总量。 如果同一 key 被多个事件持续累加，count 反映所有增量的合计；它与某个元素的查询值不是同一个维度。
4. 检查业务是否接受近似。 如果业务要求逐条精确审计、精确对账或必须解释每一次碰撞，就不应只依赖 Count-Min Sketch，应该另配精确存储或抽样校准。

一张速查表

常见问题

CMS.INFO 返回的 width 能直接换算成元素数量吗？

不能。width 是每行桶数，不是元素去重数量；同一行的桶会承载多个元素经过哈希后的计数。

depth 越大，查询结果就一定越精确吗？

不能只看 depth。深度增加了独立哈希行，误差还与 width、误差率、数据分布和累计增量有关，最终仍要按业务阈值解释。

count 为什么和 CMS.QUERY 的结果对不上？

这是正常的维度差异：count 是整张草图的累计增量，CMS.QUERY 返回某个元素的估计频次；此外，碰撞还可能让后者偏高。