Redis集群提取所有Keys脚本实现

本文深入解析了在Redis集群环境下如何安全、高效地提取全量Keys的完整技术方案，直击SCAN命令无法跨节点扫描的核心痛点，系统性地讲解了通过CLUSTER NODES动态识别所有主节点、逐节点执行SCAN迭代扫描、合理设置COUNT参数以平衡性能与稳定性、严格校验游标终结状态、规避KEYS命令禁用陷阱、以及应对并行扫描中的数据丢失与重复等关键挑战，并强调了生产环境下的风险规避策略（如避开迁移期、验证节点连通性、分文件落盘+去重校验等），为运维和开发人员提供了一套可落地、可扩展、高可靠性的全量Key提取实践指南。

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 或 Python set 去重，别依赖顺序合并
• 加校验：记录每节点返回 key 总数 + 游标终结状态，运行完比对节点数是否一致
• 别在生产高峰跑——SCAN 虽不阻塞，但高频调用仍会抬高 CPU 和网络负载

真正麻烦的是跨槽迁移未完成时的边界情况：某个 key 正在从 A 迁到 B，SCAN 可能在两边都出现，也可能都不出现。这种一致性问题没有银弹，只能尽量选迁移空闲期操作。

到这里，我们也就讲完了《Redis集群提取所有Keys脚本实现》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！