Redis游标迭代器（过滤器）scan

有这么一个案例，Redis 服务器存储了海量的数据，其中登录用户信息是以 user_token_id 的形式存储的。运营人员想要当前所有的用户登录信息，然后悲剧就发生了：因为用了 keys user_token_* 来查询对应的用户，结果导致 Redis 假死不可用，以至于影响到线上的其他业务接连发生问题。并且这个假死的时间是和存储的数据成正比的，数据量越大假死的时间就越长，导致的故障时间也越长。

如何解决这种查询的情况？

在 Redis 2.8 之前，我们只能使用 keys 命令来查询我们想要的数据，但这个命令存在两个缺点：

1. 此命令没有分页功能，我们只能一次性查询出所有符合条件的 key 值，如果查询结果非常巨大，那么得到的输出信息也会非常多；
2. keys 命令是遍历查询，因此它的查询时间复杂度是 o(n)，所以数据量越大查询时间就越长。

在 Redis 2.8 时推出了 Scan

scan cursor [MATCH pattern] [COUNT count]

• cursor：光标位置，整数值，从 0 开始，到 0 结束，查询结果是空，但游标值不为 0，表示遍历还没结束；
• match pattern：正则匹配字段；
• count：限定服务器单次遍历的字典槽位数量（约等于），只是对增量式迭代命令的一种提示（hint），并不是查询结果返回的最大数量，它的默认值是 10。

但有两个注意问题

1. 查询的结果为空，但游标值不为 0，表示遍历还没结束；
2. 如果设置了 count 10000，但返回是不固定的，这是因为 count 只是限定服务器单次遍历的字典槽位数量（约等于），而不是规定返回结果的 count 值。

scan其他命令

1. HScan 遍历字典游标迭代器
2. SScan 遍历集合的游标迭代器
3. ZScan 遍历有序集合的游标迭代器

查询规则

• 它可以完整返回开始到结束检索集合中出现的所有元素，也就是在整个查询过程中如果这些元素没有被删除，且符合检索条件，则一定会被查询出来；
• 它可以保证不会查询出，在开始检索之前删除的那些元素。

缺点：

• 一个元素可能被返回多次，需要客户端来实现去重；
• 在迭代过程中如果有元素被修改，那么修改的元素能不能被遍历到不确定。

 

 

总结：

查询命令：

1. Scan：用于检索当前数据库中所有数据；
2. HScan：用于检索哈希类型的数据；
3. SScan：用于检索集合类型中的数据；
4. ZScan：由于检索有序集合中的数据。

查询注意：

1. Scan 可以实现 keys 的匹配功能；
2. Scan 是通过游标进行查询的不会导致 Redis 假死；
3. Scan 提供了 count 参数，可以规定遍历的数量；
4. Scan 会把游标返回给客户端，用户客户端继续遍历查询；
5. Scan 返回的结果可能会有重复数据，需要客户端去重；
6. 单次返回空值且游标不为 0，说明遍历还没结束；
7. Scan 可以保证在开始检索之前，被删除的元素一定不会被查询出来；
8. 在迭代过程中如果有元素被修改， Scan 不保证能查询出相关的元素。