SCAN在Redis集群中不能扫全量key，因为其仅作用于当前连接节点，需手动遍历所有主节点；应通过CLUSTER NODES筛选master节点，用SCAN 0 MATCH * COUNT 1000逐节点扫描并去重校验。
SCAN 在 Redis 集群里为什么不能直接扫全量 key
因为 Redis 集群是分片的，SCAN 命令只作用于当前连接的节点，它不知道其他主节点的存在。你连上一个节点执行 SCAN，只能拿到该节点负责的那部分 key（即 CRC16(key) % 16384 落在该节点哈希槽范围内的 key）。想凑齐全量，必须手动连每个主节点分别扫。
怎么识别集群里所有主节点
最可靠的方式是用 redis-cli --cluster check 或直连任一节点执行 CLUSTER NODES，再过滤出带 master 角色且无 fail 状态的行。注意别把从节点或已下线节点算进去。
实操建议：
- 用
redis-cli -h {host} -p {port} CLUSTER NODES获取原始输出 - 用
awk或 Python 过滤：找包含master且不含fail和noaddr的行，提取 IP:port - 确认端口可连通（有些节点可能防火墙拦了，
telnet或nc -z快速验证） - 避免硬编码节点列表——集群扩缩容后会失效
SCAN 参数选错会导致漏 key 或卡死
SCAN 不是“一次扫完”，它靠游标迭代，COUNT 只是提示值，实际返回数量不保证。在大 key 多或内存紧张的节点上，小 COUNT（比如 10）会让请求次数暴增；太大（比如 10000）又可能阻塞单次响应。
推荐配置：
- 统一用
SCAN 0 MATCH * COUNT 1000起手，平衡速度和压力 - 必须检查返回游标是否为
"0"才算本轮结束（字符串 "0"，不是数字 0） - 不要用
KEYS *—— 集群模式下报错(error) ERR This Redis command is not supported in cluster mode - 如果业务允许模糊匹配，把
MATCH写具体些（如MATCH user:*），减少无效遍历
脚本汇总结果时容易丢数据或重复
多个节点并行 SCAN 时，若简单拼接结果文件，可能因网络延迟、重试逻辑缺失、超时中断导致某节点部分 key 漏掉；若没去重，又可能因故障转移期间哈希槽临时双写造成少量重复（虽然概率低，但全量统计场景下不可忽略）。
稳妥做法：
- 每个节点单独存一个
keys_node_127.0.0.1_7001.txt文件，先确保单节点完整 - 汇总阶段用
sort -u或 Pythonset去重，别依赖顺序合并 - 加校验：记录每节点返回 key 总数 + 游标终结状态，运行完比对节点数是否一致
- 别在生产高峰跑——
SCAN虽不阻塞，但高频调用仍会抬高 CPU 和网络负载
真正麻烦的是跨槽迁移未完成时的边界情况：某个 key 正在从 A 迁到 B，SCAN 可能在两边都出现，也可能都不出现。这种一致性问题没有银弹，只能尽量选迁移空闲期操作。
