Redis SCAN 迭代期间删除键会不会漏掉后续键

会，但要先分清“漏掉”的对象。Redis SCAN 不是一次性快照：如果一个键从迭代开始到游标再次回到 0 之前一直存在，完整迭代保证它会在某次返回中出现；如果这个键在扫描中被删除、重新加入，或者是扫描期间才新增的，Redis 只给出有限保证，它可能被返回，也可能不被返回。删除已经返回的键本身，不等于后面的稳定键都会被跳过。

Redis SCAN 的完整迭代到底保证什么

SCAN 每次只返回一小批键，并把下一次要使用的游标一起返回。只有返回游标重新变成 0，才表示这一轮结束。Redis 官方对完整迭代给了两个关键保证：开始时就在集合中、并且一直保持到结束的元素，最终会被返回；开始前已经删除且整轮没有重新加入的元素，不会被返回。

这两个保证针对的是“完整迭代”和“元素持续存在”这两个条件，不是对某一次 SCAN 调用的快照承诺。COUNT 只是服务器每次工作的提示值，不是固定页大小，也不能用“本次返回数量少”判断后续没有键。

删除当前返回键时哪些情况可能漏掉

把删除动作按时间拆开，结论会清楚很多。

因此，最常见的批量清理场景通常可以直接删除 SCAN 返回的键：即使同一个键再次返回，DEL 或 UNLINK 对已经不存在的键也不会把数据恢复出来。真正需要警惕的是业务还在持续写入同一匹配范围，此时一轮 SCAN 结束只说明游标归零，不代表期间新增的键已经全部被处理。

用 SCAN 配合删除命令做安全清理

下面的 Python 骨架把“游标是否结束”和“本批是否有键”分开判断，并把删除作为可重复操作。生产环境中如果键值很大，优先评估 UNLINK 对异步释放内存的影响；如果需要严格同步删除，再使用 DEL。

cursor = 0
while True:
    cursor, keys = client.scan(cursor=cursor, match="cache:session:*", count=200)
    for key in keys:
        # 同一键可能重复返回，清理动作必须允许重复执行。
        client.unlink(key)

    # 只有游标回到 0 才结束，不能用 keys 为空提前退出。
    if cursor == 0:
        break

这里的 COUNT 200 只是调节每次工作的量，不能当成“每页 200 个”。匹配过滤也可能让某次返回为空，但游标仍然没有回到 0，所以循环必须继续。

并发删除场景的复查清单

如果问题是“为什么清理后还有匹配键”，先不要直接把原因归结为 SCAN 跳过。按下面顺序检查：

• 是否真的把游标从 0 跑到 0，中间有没有把空批次当结束？
• 清理期间是否还有生产者不断写入新的 cache:session:* 键？
• 是否存在多个清理 worker，各自扫描同一 keyspace，导致重复处理或日志顺序混乱？
• 业务是否要求“这一时刻以前的键全部清掉”？如果要求严格边界，应先停写、记录边界，再扫描，必要时做第二轮复查。

可以记录扫描开始时间、结束游标、匹配键数量、重复键数量，以及扫描完成后的独立抽样结果。若必须在不停写的情况下收敛，更适合给键加入批次标记或时间边界，再按标记清理；不要把 SCAN 当作带快照时间点的分页接口。

常见问题

删除 SCAN 当前返回的键会不会让下一个游标失效？

删除当前返回键通常不会让客户端游标失效，下一次仍应使用 Redis 返回的游标继续调用。需要注意的是，集合在迭代中变化后，变化元素的返回结果不再有稳定快照语义。

SCAN 返回空数组是不是已经遍历完了？

不是。只有游标等于 0 才表示完整迭代结束；COUNT、MATCH 都可能让某次调用没有匹配键。

如何避免重复删除同一个键？

优先让删除动作幂等，通常不必为每个键维护集合。若删除动作还包含发消息、扣库存等副作用，再单独用去重集合、任务状态或批次标记保护副作用，而不是把 SCAN 当作不会重复的迭代器。

参考：Redis SCAN 官方命令文档。