马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？立即注册
x
一、SCAN 下令的核心价值
Redis 的 KEYS * 下令虽然可以遍历所有键，但在生产情况中直接使用可能导致服务壅闭（时间复杂度 O(n)）。SCAN 下令通过游标分批次迭代，实现非壅闭式遍历，成为处理百万级键的安全选择。
二、下令语法与参数解析
1. 底子语法
- SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]
参数作用cursor游标值，初次传入 0，后续使用前次返回的游标MATCH模式匹配，如 user:* 过滤以 “user:” 开头的键COUNT建议返回数量（默认 10），实际返回可能不同，不影响迭代完备性TYPE指定键范例（Redis 6.0+），如 string、hash、list 等
三、使用示例
1. 底子迭代
- # 第一次迭代
- 127.0.0.1:6379> SCAN 0
- 1) "17" # 下次迭代的游标
- 2) 1) "user:1001"
- 2) "product:2023"
- 3) "session:abcd"
- # 基于新游标继续
- 127.0.0.1:6379> SCAN 17
- 1) "0" # 游标归零，迭代完成
- 2) 1) "order:5678"
- # 查找以 "prod" 开头的键，每批最多 50 个
- 127.0.0.1:6379> SCAN 0 MATCH prod* COUNT 50
- 1) "23"
- 2) 1) "prod:100"
- 2) "prod:101"
- # 仅返回 Hash 类型键
- 127.0.0.1:6379> SCAN 0 TYPE hash
- 1) "5"
- 2) 1) "user:profile:1001"
- 2) "product:meta:2023"
四、SCAN 的核心特点
1. 非壅闭迭代
- 原理：基于字典槽（slot）分批次遍历，每批耗时 O(1)
- 优势：避免单次操作长时间壅闭主线程
2. 不保证完全一致性
- 体现：迭代期间新增/删除的键可能被包含或遗漏
- 原因：采用“快照”机制，但非强一致性视图
3. 可能返回重复键
- 概率：约 10%-20% 的重复率（取决于数据修改频率）
- 处理：客户端需自行去重
4. 实用场景
- 统计键数量、导出匹配模式的键
- 定期整理过期数据（联合 TTL 检查）
- 大数据量的键空间分析
五、SCAN 家族下令
下令作用示例SSCAN遍历集合元素SSCAN myset 0 MATCH a*HSCAN遍历哈希表字段HSCAN user:1001 0ZSCAN遍历有序集合成员ZSCAN rankings 0
六、注意事项与最佳实践
1. COUNT 参数调优
- 小值（如 10）：适合网络延迟敏感场景
- 大值（如 1000）：适合内网低延迟情况
- 建议：根据均匀键巨细和网络条件动态调解
2. 客户端去重方案
- # Python 示例：使用集合去重
- seen = set()
- cursor = 0
- while True:
- cursor, keys = redis.scan(cursor, match='user:*', count=100)
- for key in keys:
- if key not in seen:
- process(key)
- seen.add(key)
- if cursor == 0:
- break
- 游标持久化：不要存储游标（可能失效）
- COUNT 误解：实际返回数量可能大于设定值
- 超时处理：添加超时机制防止无限循环
七、性能对比（10万键测试）
操作耗时CPU 峰值内存波动KEYS *320ms95%50MB↑SCAN15ms15%2MB↑
总结
SCAN 下令是 Redis 高可用设计的典范，通过游标分批、非壅闭式遍历，完美平衡了数据遍历需求与服务稳固性。公道运用 MATCH 过滤、COUNT 调优及客户端去重，可高效应对海量数据场景。在需要精确一致性的场景中，仍需谨慎评估或联合事件处理。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
