为何sscan显示不存在的键？如何获取集合准确元素计数？

1. 为什么sscan A 0会返回不存在的元素X？ #

这是因为Redis的sscan命令是弱一致性遍历，它的工作机制决定了可能返回已删除的元素：

• Redis集合的底层存储是哈希表或整数集合，当你删除集合中的元素时，Redis不会立即清理哈希表中对应的槽位，只会标记该槽位为已删除状态。
• sscan基于游标遍历这些槽位时，会把标记为删除的槽位中的旧元素返回，但实际上这些元素已经不在集合里了。
• 你验证的ttl X返回-2、exists X返回0，说明X确实不是数据库中的独立键，但它曾经是集合A的成员，删除后被sscan的弱一致性特性扫了出来。

注意：sscan的设计目标是高效遍历大集合，而非保证强一致性，所以还可能出现漏掉新增元素的情况。如果需要确认返回的元素是否真的在集合中，可以用sismember A X做二次验证。

2. 为什么scard A的结果比info keyspace的总键数大两倍？ #

这完全是对两个统计维度的误解：

• info keyspace中的keys统计的是Redis数据库中独立键的数量（比如集合A、字符串键B、哈希键C等，每个独立键算1个）。
• scard A统计的是集合键A内部包含的成员数量，这些成员是集合键的“值”的一部分，不属于独立的数据库键。

举个简单例子：你可以只创建1个集合键，往里面塞100万个元素，此时info keyspace显示键数为1，scard显示100万——这完全正常。你的场景中，数据库有59万多个独立键，而集合A本身包含121万多个成员，两者没有大小限制的关联，完全合理。

3. 如何获取集合的准确元素计数？ #

直接用scard A就可以！

• scard是O(1)复杂度的命令，它直接读取集合内部维护的计数变量（哈希表的ht->count或整数集合的length），返回的结果是绝对准确的。
• 如果你之前想用sscan来统计元素数量，这是不合适的，因为弱一致性会导致统计结果出现重复或遗漏。sscan适合分批遍历处理元素，但计数的话scard是最优解。

内容的提问来源于stack exchange，提问作者Benubird