Redis扫描大key利器Scan命令探秘

scan命令有什么用？

核心作用来解决KEYS命令阻塞问题而设计的非阻塞式遍历命令。它的核心思想是分批次、游标式遍历，每次只返回少量数据，避免长时间占用主线程。

底层原理

1. 游标迭代机制

javascript 复制代码

# 示例
redis-cli scan 0 match "user:*" count 1000
# 返回：1) "12345"  # 下一次迭代的游标
#       2) 1) "user:1001"
#          2) "user:1002"
#          ... # 最多1000个key

工作流程：

复制第一次调用：scan 0 count 1000 → 返回游标12345 + 1000个key
第二次调用：scan 12345 count 1000 → 返回游标67890 + 1000个key
第三次调用：scan 67890 count 1000 → 返回游标0 + 剩余key（遍历完成）

2. 为什么不会阻塞主线程

底层数据结构：字典的渐进式rehash
Redis使用字典（dict）存储所有键值对，字典内部采用哈希表实现。当哈希表需要扩容时，Redis会进行渐进式rehash：
SCAN命令的遍历逻辑：

1）检查rehash状态：如果字典正在rehash，同时遍历ht $0$ 和ht $1$

2）按桶遍历：每次只处理一个哈希桶（bucket），而不是全表扫描

3）记录游标：游标对应的是哈希桶的索引位置

4）分批返回：处理完指定数量的桶后立即返回，不阻塞

3.与Keys命令对比
4. SCAN命令的局限性

虽然SCAN是安全的，但需要注意：

1.不保证原子性：在遍历过程中，可能有key被删除或新增
2.重复key问题：在rehash过程中，同一个key可能被返回多次
3.游标失效：如果字典结构发生重大变化（如rehash完成），游标可能失效

5.总结

SCAN命令的生产环境安全性源于其渐进式遍历机制：

分批次处理：每次只处理少量哈希桶，立即返回
游标记录状态：下次调用从上次位置继续
支持rehash：在字典扩容时也能正确遍历
可控制批次大小：通过count参数调整每次返回的key数量

这种设计使得SCAN命令可以在不阻塞主线程的情况下完成全量遍历，是生产环境扫描大Key、统计数据等操作的唯一安全选择。相比之下，KEYS命令会一次性扫描所有key，在数据量大时可能阻塞Redis数秒甚至更长时间，严重影响线上服务。