异地多活灾备需确保slot映射一致、断点续传可靠及写冲突兜底；redis-shake必须显式配置cluster=true并填全master节点列表，否则将误作单机处理导致所有key写入同一分片而触发MOVED错误。
异地多活灾备不是“配好 redis-shake 就能跑”，核心难点在于 slot 映射一致性、跨地域网络抖动下的断点续传能力，以及写冲突时的业务兜底逻辑。直接套用默认配置大概率在切换时丢数据或报 MOVED 错误。
sync 模式下必须显式声明 cluster = true 并填全 master 节点列表
redis-shake 不会自动发现集群拓扑——它只按你给的 nodes 列表去拉取分片数据。如果只填一个源节点地址（比如 "10.10.1.1:7000"），它就当单机处理，跳过 slot 计算和分片路由，所有 key 全部写进目标集群的同一个分片，恢复后查任何 key 都返回 MOVED。
正确做法是：
- source 和 target 配置块中都设
cluster = true -
nodes字段必须列出**全部 master 节点地址**（至少一个，但推荐全列，避免某节点临时不可达导致部分 slot 拉不到） - 不要把密码拼在 URL 里（如
redis://:pwd@host:port），集群模式下部分节点可能返回NOAUTH；统一用auth_password字段 - 若目标集群启用了 Redis 6+ ACL，还需配
auth_user = "default"（或其他有写权限的用户）
增量同步阶段频繁报 MOVED/ASK 或 key 消失？先检查目标集群 slot 分布
这几乎 100% 是目标集群 slot 映射异常：要么有 master 节点 disconnected，要么 slots 范围重叠或空缺，导致 redis-shake 算出的 slot 在目标侧找不到对应 owner。
快速验证命令：
redis-cli -c -h <target-host> -p <port> cluster nodes
重点关注：
- 每行第一个字段是否为
master角色，且connected状态为connected - 每行末尾的 slot 范围是否连续无重叠（如
0-5460、5461-10922、10923-16383） - 是否有节点显示
fail或 slot 迁移中（含[migrate]标记）
修复前别启动 redis-shake，否则写入会失败并堆积在内存 buffer 中，最终触发 OOM。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
write_mode = "sync" 时并发数不是越高越好
很多人以为调高 concurrent 就能加速同步，结果目标集群 CPU 或内存打满，反向拖慢整个 pipeline。redis-shake 的 Cluster Writer 是按 slot 分发写请求的，每个 slot 对应一个独立 writer goroutine，所以并发上限实际受限于目标集群的 master 数量和资源余量。
生产建议值：
- 3 主集群：设
concurrent = 8起步，观察目标redis-cli info memory | grep used_memory_rss增长趋势 - 6 主集群：可尝试
concurrent = 12~16，但需确保目标节点maxmemory有 20% 以上余量 - 一旦出现
OOM command not allowed或大量timeout日志，立刻降回8
注意：concurrent 控制的是写入并发，不影响读取；读取并发由源集群 master 数量自动决定。
跨地域场景必须开启断点续传与日志缓冲
公网跨地域链路不稳定，TCP 连接中断、PSYNC 失败、AOF 传输卡住都是常态。redis-shake 默认不持久化同步位点，一断就得从头来。
关键配置项：
-
sync_reader.rdb_backup = true：全量阶段生成本地 RDB 备份，断点后可跳过已下载部分 -
sync_reader.aof_buffer_size = 134217728（128MB）：增大 AOF 环形缓冲区，扛住短时网络抖动 -
sync_reader.checkpoint_interval = "30s"：每 30 秒刷一次同步位点到本地文件，避免重启丢进度 -
log.level = "info"以上，重点盯checkpoint save success和psync failed, retry日志
这些配置不加，同步过程看似跑得欢，其实随时可能因一次 200ms 网络延迟就彻底崩掉，再起来要重跑全量。
真正难的不是让 redis-shake 启动，而是让它在弱网、扩容、failover 场景下持续稳定推进位点——这要求你对源/目标集群的 slot 状态、资源水位、网络质量都有实时感知，不能只盯着 sync 进程是否存活。
