redis-shake 是阿里开源的 redis 数据迁移同步工具，支持 dump/sync/rump 三种模式，可跨集群、版本及部署形态同步，能正确处理 slot 映射、ask/moved 重定向、acl/ssl 等，而原生 redis-cli --rdb 无法替代。

redis-shake 是什么，能不能直接替代 dump/rdb 同步

redis-shake 不是 Redis 官方工具，但它是阿里开源的、专为 Redis 数据迁移和同步设计的高可用工具，支持 dump（离线）、sync（实时增量）、rump（从 RDB 恢复）三种模式。它能跨集群、跨版本（如 4.x → 7.x）、跨部署形态（单机 ↔ 集群 ↔ 哨兵）工作，而原生 redis-cli --rdb 或 SAVE/BGSAVE 只能导出全量 RDB，无法处理集群 slot 映射、ASK/MOVED 重定向、密码鉴权等细节。

常见错误现象：redis-cli --rdb 直接连集群任意节点导出 RDB，结果恢复后 key 全部落在一个分片，查询报 MOVED 错误；或因密码/ACL 权限缺失导致连接被拒。

• redis-shake 会自动识别集群拓扑，按 slot 分片拉取数据，写入目标集群时也严格遵循 slot 分布
• 支持 auth、user（Redis 6+ ACL）、SSL、Proxy（如 Twemproxy）等真实生产环境配置
• 不依赖源集群开启 rdb save，对业务影响小；增量同步还能持续 catch up 直到切换窗口

怎么配置 redis-shake 做集群到集群的 sync 同步

核心是两个配置块：source 和 target，必须显式声明为 cluster 类型，并提供完整节点列表（非仅一个入口）。

典型易错点：只填一个源节点地址，redis-shake 会当作单机处理，跳过集群发现逻辑，导致 key 写错 slot；或目标集群密码写在 URL 里（如 redis://:pwd@host:port），但集群模式下部分节点可能返回 NOAUTH —— 正确做法是统一用 auth_password 字段。

• 源配置中 cluster = true，nodes 列出全部 master 节点（至少一个，推荐全列），例如：["10.0.1.1:7000", "10.0.1.2:7001"]
• 目标配置同样设 cluster = true，nodes 填目标集群所有 master 地址；若目标启用了 ACL，需配 auth_user = "default" + auth_password = "xxx"
• 关键开关：write_mode = "sync"（不是 dump），filter.key = "*" 可按需过滤，concurrent 建议设为 8–16，过高反而触发目标集群 OOM command not allowed

同步过程中 key 消失或报 MOVED/ASK 怎么排查

这基本指向 slot 映射失败：源集群的 key 计算出的 slot，在目标集群没有对应 master 节点负责，或节点状态异常（如 failover 中、slot 迁移未完成）。

先确认目标集群健康：redis-cli -c -h target-host -p 6379 cluster nodes 看是否所有 master 的 connected 为 connected，且 slots 范围无重叠或空缺；再检查 redis-shake 日志里是否有 slot xxx not found in target cluster。

• 源集群做了 slot 迁移但未 finish？redis-shake 会卡住，需等迁移完成再启动
• 目标集群刚创建，用 redis-cli --cluster create 时没加 --replicas 1 导致只有 master 无 replica？不影响 sync，但影响高可用
• 目标集群开启了 cluster-require-full-coverage no？务必设为 yes，否则部分 slot 无主时 redis-shake 写入会失败

如何验证同步结果一致且不丢数据

不能只比 key 数量 —— 集群模式下 KEYS * 不可用，且不同节点 key 数天然不等。真正有效的验证是抽样校验 + 增量断点比对。

推荐组合操作：redis-shake 自带 diff 模式（需提前用 dump 模式导出源/目标快照），但更轻量的是用 redis-cli --cluster check 对两边分别跑一致性检查，再人工抽 3–5 个 slot，用 redis-cli -c -h src -p p1 cluster getkeysinslot {slot} 100 拿 key 列表，逐个 GET 比对 value 和 TTL。

• 重点看带 {} 标签的 key（如 user:{1001}:profile），它们强制落在同一 slot，最容易暴露哈希偏移问题
• 同步期间新写入的数据，要确认 redis-shake 日志末尾有类似 synced until offset: 123456789，且目标集群 INFO replication 中 master_repl_offset 与之接近（差值
• 如果业务允许停写，最后 stop write → 等 redis-shake lag 归零 → 执行一次 flushall 清掉残留旧 key → 切流量

最常被忽略的是目标集群的 maxmemory 设置：即使总内存够，单个 shard 内存超限会导致写入静默失败，redis-shake 日志只会报 write error: OOM command not allowed，得挨个查每个 master 的 INFO memory。