MIGRATE命令支持原子性批量迁移，需用KEYS子句配合空key参数，适用于内网TCP可达、目标DB已就绪的场景，配合COPY/REPLACE、合理timeout及SCAN分批策略可实现平滑无损迁移。
用 MIGRATE 在两个独立 Redis 生产集群间平滑无损迁移 key，核心是保证原子性、避免阻塞、不丢数据、不覆盖误删。它不是简单执行一条命令，而是一套配合策略。
明确 MIGRATE 的适用边界
MIGRATE 本质是单 key 原子迁移（源 dump → 网络传输 → 目标 restore → 源 del），但 Redis 3.0.6+ 支持批量 key 迁移，只需把 key 参数留空，并用 KEYS 子句列出所有待迁 key。这点很关键——它比循环调用单 key MIGRATE 更高效，也比 DUMP/RESTORE 脚本更可靠（因内置超时、错误重试和原子语义）。
- 只适用于 TCP 可达的两个集群节点之间（不能跨公网裸连，需走内网或隧道）
- 目标集群必须提前创建好对应 db（如迁往 db 1，则目标实例需启用 db 1）
- 不支持带密码的集群直连？错——可用
AUTH password或AUTH2 username password显式认证 - 迁移过程中源集群该 key 所在连接会被短暂阻塞，但不影响其他 key 读写
构造安全可控的批量迁移命令
不要手写几百行 shell 脚本遍历 keys，容易 OOM 或触发 KEYS * 阻塞。推荐分批 + pipeline + 参数化方式：
- 先用
SCAN替代KEYS *获取 key 列表，例如：redis-cli -h src-host -p 6379 -a src-pass --scan --pattern "user:*" | head -n 500 - 将这批 key 拼成
MIGRATE dst-host 6379 "" 0 5000 COPY REPLACE KEYS key1 key2 key3...形式（注意：KEYS 后最多支持约 1000 个 key，超了就拆批） - 加上
COPY保留源数据，上线验证通过后再统一清理；加REPLACE避免目标已存在同名 key 报错 - timeout 设为 5000ms 起步，大 value（如 >1MB）可提到 30s，防止网络抖动中断
生产环境必须做的三件事
平滑 ≠ 静默。真正无损的前提是可观测、可回退、可验证：
-
监控迁移进度与失败率：用
redis-cli --stat观察源/目标 QPS 和内存变化；记录每批返回结果，捕获(error) ERR...类响应并重试 -
开启增量同步兜底：迁移期间新写入的 key 不会自动同步。建议在迁移前启动
redis-migrate-tool或基于PSYNC的监听程序，把增量变更实时补到目标集群 -
校验一致性：迁移完成后，抽样对比源/目标的
GET、TYPE、TTL、STRLEN/LLEN/SCARD等值；对集合类 key，可用SDIFF或sort+ md5 校验全量内容
替代方案选型建议
如果集群规模大（千万级 key）、拓扑复杂（跨机房/跨云）、或要求真正热迁移（零感知），MIGRATE 就不够用了：
- 跨集群大规模迁移 → 用
redis-migrate-tool：支持断点续传、多线程、自动分片映射、状态可视化 - 单机迁入集群 → 用
redis-cli --cluster import：自动做 hash slot 分配，适配集群协议 - 需要长期双写过渡 → 自研 proxy 层或用
RedisGears实现写扩散，而非依赖一次性迁移
