scan不能直接解决延迟抖动，但能避免keys引发的尖峰阻塞：它将o(n)全量扫描拆为多次小代价请求，防止主线程被keys*锁死数百毫秒至秒级。
为什么 SCAN 不能直接解决延迟抖动，但能避免 KEYES 引发的尖峰阻塞
SCAN 不是“提速工具”，它不会降低单次操作耗时，而是把原本一次 O(n) 全量扫描拆成多次小代价请求，从而避免主线程被 KEYES * 这类命令锁死几百毫秒甚至秒级。真正导致延迟抖动的，往往是某次误用 KEYS 触发的“停服级卡顿”——此时所有请求排队等待，redis-cli --latency-history 会看到明显毛刺，而慢日志里可能只有一条 KEYS * 记录。
常见错误现象：
- 监控显示 Redis P99 延迟突然跳到 800ms+，持续数秒，之后回落
- 应用层报大量
RedisConnectionTimeoutException或JedisConnectionException - 运维平台发现某时段连接数暴涨、CPU 短暂打满，但内存/网络无异常
如何确认是 KEYES 导致的抖动而非其他原因
先排除硬件和配置干扰，再聚焦命令本身。重点查三处：
- 打开慢日志：
CONFIG SET slowlog-log-slower-than 10000（记录 >10ms 的命令），然后SLOWLOG GET 10看是否高频出现KEYS - 检查客户端调用栈：搜索代码中是否有
redisTemplate.keys("*")、jedis.keys("user:*")等直调用 - 抓包或代理日志：某些运维脚本、备份工具、监控探针会偷偷执行
KEYS *，尤其在低峰期定时触发
注意：KEYS 在 Redis 6.0+ 虽有微调，但仍是同步全量遍历，不改变阻塞本质；集群模式下 KEYS 甚至会报错 CROSSSLOT Keys in request don't hash to the same slot，进一步暴露问题。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
SCAN 替代 KEYES 的实操要点与易错点
不是简单替换命令，而是重构调用逻辑。关键差异在游标管理和结果可靠性：
-
SCAN必须循环调用：起始游标为0，每次取回新游标值，直到返回游标为0才结束；传错类型（如字符串"0"当整数）会导致无限循环 -
COUNT是 hint，不是 limit：设COUNT 500可能返回 0～800 个 key，尤其在哈希表 rehash 期间或数据稀疏时；不要依赖它做分页计数 - 结果可能重复或遗漏：SCAN 是弱一致性快照，遍历时新增/过期的 key 不保证命中；若需精确去重，必须在应用层用
Set缓存已见 key（注意内存膨胀风险） - 禁止在 Lua 脚本中调用：
SCAN属于非确定性命令，脚本内执行会直接报ERR Error running script
示例（Java + RedisTemplate）：
ScanOptions options = ScanOptions.scanOptions()
.match("order:*")
.count(1000)
.build();
Cursor<string> cursor = redisTemplate.scan(options);
while (cursor.hasNext()) {
String key = cursor.next();
// 处理 key
}
cursor.close(); // 必须关闭，否则连接泄漏</string>
SCAN 在不同数据结构和存储形态下的行为差异
底层编码影响实际返回数量，容易误判“漏数据”：
- 对
Set执行SSCAN：若该 set 底层是intset（元素全为整数且数量少），则无视COUNT，一次性返回全部元素；转为哈希表后才按COUNT分批 - 对
Hash执行HSCAN：同样，ziplist编码时直接全量返回；只有升级为哈希表后才支持游标分片 - 集群模式下：
SCAN只作用于当前节点，需客户端遍历所有 slot 并聚合结果；而KEYS在集群中根本不可用
最常被忽略的是高位进位法对游标迭代的影响：rehash 过程中，SCAN 使用二进制高位进位游标遍历，才能避免因桶顺序重排导致的重复或遗漏——但这完全由 Redis 内部实现，客户端只需确保游标类型正确、不跳步即可。
