独立 Redis 服务实例数据同步方案实战选型

项目背景：近期做一个项目，正好遇到两个独立的业务系统有两套独立的Redis服务器数据同步的需求，当时主要考虑采用数据API接口，从Redis服务器的key获取value值，通过API接口实时传输到另一个业务系统，再Set写入进另一个Redis服务实例，这也是一般项目研发相对的最为普通方案，当然这个实时性就差的非常多。从源Redis（A）——业务系统（A）封装API接口——业务系统（B）读取API接口——目标 Redis（B）写入，这是一个“漫长”的同步过程。另外还要考虑源Redis数据的修改、删除等异常操作，通过数据API接口的方式显然效率太低，且要处理的业务代码逻辑也非常复杂，且很容易出现错误。

项目需求：源 Redis（A）、目标 Redis（B），网络互通；原生主从是单向复制，目标库会清空原有数据；如果目标不能被清空，要用 redis-shake 这类工具。

实现方案：根据选型方案比较，采用Redis-Shake方案，当天上午讨论需求与方案，下午在UAT环境验证测试，非常高效，如果改为数据API方式，估计开发、测试与联调要一周时间，还无法保证会有各种bug问题。

方案 1：原生主从复制（最简单，适合同机房实时单向同步）

适用场景：B 是空实例，可以被清空，持续实时同步 A 的数据，A 写，B 只读，一主一从。 原理：B 作为 A 的 replica，先全量 RDB 同步，之后长连接增量同步写命令Redis。

操作

1. 登录目标 Redis B，执行：

replicaof 源A的IP 6379

带密码场景（redis6+ACL）：源配置 requirepass，从节点配置masterauth xxx。 2. 查看状态：info replication，看 master_link_status:up 即为正常。 3. 停止同步（断开主从，B 变回独立主库）：

replicaof no one

✅优点：原生自带、零额外组件、实时同步 ❌缺点：

• 目标库原有数据会被清空，这是最大坑

• 单向同步，不能双向互相同步

• 跨机房 / 跨云网络抖动容易触发全量重同步

• 源 Redis 必须开放网络访问

注意：主从是异步复制，存在短暂数据延迟。

方案 2：Redis-Shake（生产最常用，跨机房 / 跨云迁移 + 实时增量同步）

适用场景：目标不能清空原有数据、跨机房、跨云、Redis 版本不一致、需要零停机迁移，支持全量 + 增量，不会清空目标库原有 key（同名 key 会被覆盖）Alibaba Cl...。

阿里开源，模拟 psync 协议，伪装成从节点消费源 Redis 的 RDB + 复制流，写入目标 Redis。

流程：全量同步 → 持续增量同步，可以一直保持同步，也可以同步完数据后停止。 ✅优点：

• 不删除目标库原有 key（只覆盖同名 key）

• 跨机房、跨云、不同版本 Redis 之间同步

• 支持集群、单机、云厂商托管 Redis ❌缺点：需要独立部署 redis-shake 进程，需要维护。

简单配置示例（redis-shake.toml）

source.type = "standalone"
source.address = "127.0.0.1:6379"
source.password = "source_pwd"
target.type = "standalone"
target.address = "127.0.0.2:6379"
target.password = "target_pwd"

方案 3：RDB 文件备份恢复（一次性离线全量同步，不实时）

适合一次性迁移，不需要持续同步。

1. 源 Redis 执行bgsave，生成 dump.rdb

2. 将 rdb 文件拷贝到目标 Redis 的数据目录

3. 停目标 Redis，替换原 dump.rdb，重启 Redis

⚠️目标原有数据全部被覆盖，停机操作。

✅简单，不需要网络互通（文件拷贝） ❌非实时，只能某一时间点快照，无法同步增量写入。

方案 4：MIGRATE / DUMP+RESTORE（少量 key 迁移，不适合大数据量）

适合少量 key 一次性迁移，不做持续同步。

# 原子迁移单个key，迁移成功后源会删除该key
MIGRATE target_ip 6379 "" 0 5000 KEYS mykey

✅单 key 粒度，灵活 ❌大数据量性能差，阻塞 Redis，不适合持续同步。

方案选型速查表

重要避坑点

1. 版本兼容：尽量源版本 ≤ 目标版本；高版本 Redis 同步到低版本容易出错。

2. 内存：目标 Redis 内存容量 ≥ 源 Redis 占用内存。

3. 网络：跨机房同步要关注带宽、延迟、丢包；主从网络中断会触发全量重同步，调大repl_backlog_size缓解。

4. 双向同步：Redis 原生不支持双向主从。如果需要双向双写同步（双活），原生做不到，需要用 redis-shake 双向 + 业务层处理 key 冲突（非常复杂，一般不推荐）。

5. 权限：源 Redis 需要允许 replica 连接，开放密码 / ACL。

推荐选型建议

• 同机房、目标实例是空库，做只读副本：原生 replicaof 主从复制

• 跨机房 / 跨云、目标有业务数据、零停机迁移、灾备持续同步：redis-shake

• 一次性冷迁移，不需要实时同步：RDB 文件

• 少量 key 临时迁移：MIGRATE

本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。

原文链接 https://www.yijunzhao.cn/archives/independent-redis-instance-data-sync-solutions-practical-comparison

欢迎访问 小易撩挨踢