scan不能在redis集群模式下直接指定节点执行，因其是客户端重定向命令，会按slot自动转发；正确做法是遍历16384个slot，对每个slot主节点分别scan，推荐使用redis-py-cluster等封装好的scan_all方法。
SCAN 命令不能在 Redis 集群模式下直接指定节点执行
Redis 集群（Cluster）模式下，SCAN 是一个**客户端重定向命令**：当你向任意节点发送 SCAN 时，该节点会根据当前游标（cursor）所属的哈希槽（slot），自动把请求转发（MOVED 或 ASK 重定向）到真正持有数据的那个节点。你无法通过客户端“强制”让 SCAN 只在某个物理节点上运行——集群协议本身不支持绕过 slot 路由逻辑。
这意味着：如果你硬要“在特定节点上遍历”，实际效果可能是部分 key 被跳过（因为不属于该节点负责的 slot），或触发大量重定向（影响性能和结果完整性）。
想遍历全量 key 并保证一致性，必须按 slot 分片扫描
Redis 集群的数据分布是确定性的（CRC16(key) % 16384），所以正确做法是：遍历全部 16384 个 slot，对每个 slot 找到其主节点，再对该节点执行 SCAN（带上 MATCH 和 COUNT 参数）。这样既能覆盖所有 key，又能避免跨节点重复或遗漏。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
CLUSTER SLOTS获取 slot → node 映射关系（注意：响应中每个区间对应一个主从组，取第一个地址为主节点） - 对每个 slot 区间，连接对应主节点，执行
SCAN 0 MATCH pattern COUNT 1000—— 注意游标必须从 0 开始，且每次迭代都需用上一轮返回的新游标 - 遇到
ASK重定向（如 slot 正在迁移中），需先发ASKING，再重试SCAN - 不要并发扫所有 slot：某些节点可能被压垮；建议按 slot 分批、加限速（例如每秒最多 5 个 slot）
单节点 SCAN 的常见误用与后果
有人会尝试直接连某个节点 IP:PORT，然后发 SCAN，以为能“只扫这个节点”。这在集群模式下极易出错：
- 如果 key 不在该节点负责的 slot 范围内，
SCAN返回空，但不会报错——你以为扫完了，其实漏了 99% 的数据 - 若该节点是 slave，且没开启
slave-read-only no，SCAN会被拒绝（返回READONLY You can't write against a read only slave.） - 即使连的是 master，它仍会检查 key 的 slot，对不属于自己的 key 直接忽略，不重定向（因为
SCAN是只读游标命令，集群协议未强制要求重定向） - 使用
redis-cli -c连集群时，SCAN表现不可控：它可能随机重定向，也可能卡在某次游标上不动
生产环境推荐方案：用 redis-py-cluster 或 redis-go-cluster 封装好的 scan_all
手动实现 slot 分片扫描容易出错，建议直接用成熟客户端库的内置方法，它们已处理了 slot 定位、ASK/MOVED 重试、游标状态维护等细节：
-
redis-py-cluster提供scan_iter()，调用后自动完成全集群遍历，返回 generator，内存友好 -
github.com/bsm/redisc（Go）的Cluster.ScanAll()支持 pattern、count、并发控制 - 自己写脚本？至少要用
CLUSTER NODES+CLUSTER KEYSLOT辅助验证 slot 归属，别只靠节点 IP 硬连
最常被忽略的一点：SCAN 不提供强一致性快照——遍历时其他客户端仍在写入，key 可能被删、改、迁走。如果业务要求严格一致，得配合 CLUSTER SETSLOT ... IMPORTING/IMPORTED 冻结迁移，或改用备份文件（RDB）解析。
