Redis那块儿，怎么快点算Key，顺带聊聊实现细节啥的

Redis那块儿，想快点算Key，说白了就是怎么快速统计出数据库里有多少个键，或者找出符合特定模式的所有键，这在数据量大、业务要求高的场景下，比如做实时监控、数据迁移或者清理过期数据时，是个挺实际的问题，你不能每次都慢慢悠悠地去数,那样太耽误事了。

最直接的办法就是用 KEYS 这个命令，你给它一个模式，KEYS user:*，它就把所有以 user: 开头的键都给你找出来，这个方法简单是简单，但有个致命的问题：它是阻塞式的，来源中提到，当Redis用KEYS *去遍历一个包含千万级key的库时，整个服务会卡住好几秒甚至更久，这段时间内其他所有命令都得等着，这在生产环境是绝对不能接受的，相当于为了数数让整个服务暂停了，虽然它快，但这种“快”是建立在牺牲整个服务可用性的基础上的，老司机们都会告诉你，千万别在生产环境用 KEYS。

那怎么办呢？Redis在2.8版本之后提供了一个救星命令：SCAN。SCAN 命令的核心思想是增量式迭代，或者叫游标式遍历，它不像 KEYS 那样一口吃个胖子，而是每次只扫描一小部分数据，返回一部分结果和一个新的游标（cursor），你拿到这个游标，下次请求时带上它，Redis就从上次停下的地方继续扫描，这样就把一次性的巨大计算量，打散成了很多次小的、非阻塞的操作，虽然总的时间可能比一次性的 KEYS 要长，但在这个过程中，Redis主线程可以随时处理其他命令，服务不会卡顿,这就是它最大的优势。

聊聊 SCAN 的实现细节，来源里打了个比方，说它遍历的不是我们直观理解的那个“键值对字典”，而是底层哈希表的一个个“桶”（bucket），Redis为了高效，会用哈希表来存键值对。SCAN 命令实际上是按照这个哈希表的顺序，一次遍历一个或多个桶，把桶里的键返回给你，这里有个反直觉的地方：由于哈希表在扩容时可能会重组（rehash），SCAN 命令在遍历过程中，如果字典的大小发生了变化（比如从4个桶扩到了8个桶），它会采用一种巧妙的算法，保证在遍历期间，无论哈希表是否在扩容，同一个元素都不会被返回多次，也尽可能避免遗漏,这是它实现可靠性的关键。

使用 SCAN 时，你可能会注意到几个特点，第一，它返回的元素顺序是不确定的，这跟哈希表的特性有关，第二，它可能返回重复的元素，但官方承诺在哈希表大小不变的情况下不会重复，如果遍历过程中有扩缩容，极小概率下可能会有重复，但算法已经尽力避免了,所以你的客户端代码要能处理这种潜在的不确定性和可能的重复。

在实际操作中，SCAN 的基本用法是 SCAN cursor [MATCH pattern] [COUNT count]。MATCH 让你可以像 KEYS 那样过滤键，但注意这个过滤是在数据从桶里取出来之后进行的，COUNT 参数只是提示每次遍历多少个桶，返回的元素数量可能小于 COUNT，特别是当使用 MATCH 且匹配率不高时，可能扫了很多桶，只返回零星的几个键，你需要循环调用，直到返回的游标为0,表示遍历完成。

除了直接扫描键，有时候我们想快速知道整个实例里到底有多少个key，这时候用 SCAN 去自己加和就太慢了，可以用 INFO 命令，在 INFO 命令返回的一大堆信息里，找到 keyspace 部分，它会列出每个数据库的key的数量。db0:keys=1000000,expires=100，这个数字是Redis内部维护的计数器，查询起来是O(1)的复杂度，瞬间完成，非常快。但要注意，INFO 命令输出的key数量是包括带过期时间的key的，它给出的是总key数，如果你只想知道当前有效的（未过期的）key的大概数量，这个值是准的，但如果你想精确统计符合某个模式的key的数量，那还是得靠 SCAN 加 MATCH 来自己数。

还有个 DBSIZE 命令，它直接返回当前数据库的key总数，原理和 INFO 里的计数器一样，瞬间出结果,最适合用来做快速的总量检查。

想快点算Key,得分情况：

• 要瞬间知道总key数：用 DBSIZE 或 INFO keyspace,最快。
• 要找出符合模式的所有key或精确统计数量：坚决不用 KEYS，用 SCAN 命令组合，通过游标分批非阻塞地处理，虽然总耗时可能长点,但保证服务不中断。
• 实现细节的核心：SCAN 通过遍历哈希桶和应对rehash的巧妙算法，实现了增量式、低阻塞的扫描。

最后提一嘴，如果业务上频繁需要做复杂的键统计，可能意味着数据模型或架构有优化空间，可以考虑用Redis的Set、Sorted Set等集合类型来主动维护特定key的集合，或者借助外部系统如时间序列数据库、监控系统来分担统计压力,从根源上减少临时扫描的需求。