scan不能直接替代keys,因为它是游标驱动的渐进式迭代过程,需手动循环处理cursor、分批逻辑及集群节点遍历,否则易漏数据、卡主节点或连接泄漏。

SCAN 能安全替代 KEYS,但必须手动处理游标、分批逻辑和集群适配,否则照样卡主节点或漏数据。
为什么 SCAN 不能直接写成 keys("user:*") 那样用?
因为 SCAN 是游标驱动的迭代过程,不是一次返回全部结果的函数。Redis 返回的响应里第一个值是下一次要传的 cursor,只有当它变成 0 才算结束。你如果只调一次 scan(...),大概率只拿到几百个 key 就停了——这不是 bug,是设计使然。
常见错误现象:
- 用
redisTemplate.execute()只调一次connection.scan(),结果只返回几十个 key,还以为匹配不到 - 没关闭
Cursor,导致连接泄漏,RedisConnectionUtils.releaseConnection报 warning - 在循环里反复 new
ScanOptions,但没设count,实际每次只扫约 10 个 key,遍历百万 key 要几万轮
正确做法是显式循环 + 游标更新:
Cursor<byte> cursor = connection.scan(options);
while (cursor.hasNext()) {
byte[] key = cursor.next();
keys.add(new String(key));
}
cursor.close(); // 必须关</byte>
如何控制每次 SCAN 的数量并避免慢扫描?
COUNT 参数不是硬限制,只是 Redis 的“提示”——它会影响单次返回 key 数量和底层哈希桶遍历粒度。设太小(如 count=10)会导致游标跳转频繁、网络往返多;设太大(如 count=10000)可能单次耗时突增,尤其 key 分布不均时。
推荐策略:
- 线上环境统一用
count=500~1000,平衡延迟与轮数 - 避免用
Integer.MAX_VALUE,这会让 SCAN 退化成近似KEYS的行为 - 如果 match 模式太宽(如
*:*),即使count=100也可能返回空数组——这不是没匹配到,是当前游标所在桶恰好没符合项
示例配置:
ScanOptions options = ScanOptions.scanOptions()
.match("user:*")
.count(800)
.build();
Redis 集群环境下 SCAN 为什么容易漏 key 或报错?
集群模式下,SCAN 命令只能作用于单个节点,而 key 是按 slot 分散的。如果你只连一个 master 节点执行 SCAN 0 MATCH user:*,那只会扫到落在该节点上的 key,其余 slot 的 key 完全不会出现。
典型错误:
- 直接对
JedisCluster或LettuceClusterClient调scan(),抛UnsupportedOperationException - 用
redisTemplate.getConnectionFactory().getClusterConnection()拿到连接后,没遍历所有 master 节点就退出 - 把不同 slot 的 key 混在一起批量删除,触发
JedisDataException: MOVED或CROSSSLOT
必须显式获取所有 master 节点,逐个 scan:
Map<string jedispool> nodes = jedisCluster.getClusterNodes();
for (JedisPool pool : nodes.values()) {
try (Jedis jedis = pool.getResource()) {
if (!jedis.info("replication").contains("role:slave")) {
// 只对 master 扫
ScanResult<string> result = jedis.scan(cursor, scanParams);
// 合并结果...
}
}
}</string></string>
SCAN 结果要不要去重?能保证不重复吗?
不能保证。SCAN 是基于哈希表桶顺序的伪随机遍历,且 Redis 允许在遍历过程中增删 key。这意味着:
- 新增的 key 可能被扫到 0 次或 2 次(取决于插入位置和游标进度)
- 删除的 key 如果已被 cursor 越过,就不会出现在结果里
- 同一轮多次 scan 同一 pattern,结果集大小可能不一致
所以:如果你后续要 delete 这些 key,别依赖 SCAN 结果做幂等判断;如果业务要求“强一致快照”,SCAN 不适用,得换方案(比如用有序集合预存 key 列表,或加外部协调服务)。
最容易被忽略的一点:SCAN 的弱一致性不是缺陷,而是权衡。你接受它漏/重的概率,换来的是 Redis 主线程不卡、监控曲线平稳、上下游接口不超时——这个 trade-off 在绝大多数缓存治理场景里,远比“精确但阻塞”更值得选。











