Redis CLUSTER COUNTKEYSINSLOT 为什么不能代表全局键数量

把 CLUSTER COUNTKEYSINSLOT 7000 的结果当成 Redis Cluster 全局键数量，核心问题不是命令算错，而是统计范围看错了。它只返回指定哈希槽里的键数，而且只查询接收请求节点的本地数据集；请求发到不服务这个槽的节点时，结果可能就是 0。

官方地址：https://redis.io/

先把命令的统计范围限定在一个哈希槽

Redis Cluster 的键空间拆成 16384 个哈希槽。命令的语法只有一个 slot 参数，返回值是该槽中的键数，因此它回答的是“槽 7000 有多少键”，不是“整个集群有多少键”。官方文档还把它标成 O(1)，但这只描述单次本地查询的复杂度，不代表一次调用完成全局扫描。

例如，下面的命令只能作为槽级观察值。代码块里的注释解释命令意图，不是实际运行截图。

# 只查询哈希槽 7000 的键数量，不代表集群总量
redis-cli -h 10.0.0.11 -p 6379 CLUSTER COUNTKEYSINSLOT 7000

# 返回值是整数；它只对应当前节点本地看到的该槽数据

核对请求节点与槽归属

Redis Cluster 稳定时，一个槽由一个主节点服务，副本只是故障切换或特定读场景的副本数据。若把请求发给不负责槽 7000 的节点，官方定义是只查本地数据集，所以结果为 0 并不能推出槽 7000 真的为空。排查时先看拓扑，再解释计数：

# 读取集群拓扑，确认 slot 7000 属于哪个主节点
redis-cli -h 10.0.0.11 -p 6379 CLUSTER SHARDS

# 在真正服务该槽的主节点上执行单槽计数
redis-cli -h 10.0.0.21 -p 6379 CLUSTER COUNTKEYSINSLOT 7000

如果客户端能处理 -MOVED，也要区分“客户端完成重定向”和“命令本身变成全局命令”：前者只是把请求送到正确节点，后者并没有发生。

按监控目标选择全局聚合方法

先明确你要的指标。看热点分布时，按槽读取 COUNTKEYSINSLOT；看某个主节点承载量时，统计该主节点负责的槽集合；看全局键数量时，则应从拓扑得到主节点集合，在每个主节点上做一次本地统计并相加，避免把副本重复算入。

如果采用逐槽相加，必须确保每个槽只在其当前服务主节点上计数；如果采用主节点本地 DBSIZE，必须只统计主节点，并把结果标注为某个拓扑快照下的估计或观测值。监控面板最好同时展示采样时间、主节点数和迁移状态。

处理迁移窗口与重复统计风险

resharding 期间槽归属会变化，计数可能与拓扑读取不在同一时刻。Redis 当前命令文档还特别说明，在原子槽迁移操作中，正在导入或被裁剪的键会从结果中过滤掉。因此一次采样更适合回答“这个时间点看到的局部规模”，不宜包装成严格一致的全局快照。

落地时保留三项信息：拓扑来源（如 CLUSTER SHARDS）、统计节点角色（只收主节点）和采样时间。若总量突然跳变，先复查槽迁移、主从切换和采集器是否重复遍历节点，再决定是否调整告警阈值。

相关问题

访问错误节点返回 0，能说明该槽没有键吗？

不能。它首先说明该节点的本地数据集没有可返回的目标槽数据，应先确认槽归属。

把所有副本的 DBSIZE 相加可以吗？

不可以。副本保存的是复制数据，会把同一批键重复计算；全局业务量通常只汇总主节点。

为什么 O(1) 仍不适合直接做全局统计？

O(1) 只针对一次指定槽的本地命令。全局统计还要处理拓扑发现、节点遍历、网络开销和迁移时点。