一、为什么需要Redis数据迁移？

作为一个长期与Redis打交道的开发者，我经历过数次数据迁移的"血泪史"。去年公司机房搬迁时，我们用了72小时才完成3TB Redis数据的迁移，过程中踩过的坑让我深刻认识到：数据迁移不是简单的复制粘贴，而是一项需要精密规划的技术活。

常见迁移需求包括：

  1. 服务器硬件升级（比如从机械盘换SSD）
  2. 跨机房/跨地域迁移（业务扩展需要）
  3. Redis版本升级（如从3.x升级到7.x）
  4. 数据合并/拆分（业务调整导致）
  5. 云服务迁移（自建Redis迁移到云Redis）

二、Redis迁移的五种兵器谱

2.1 冷兵器：RDB/AOF文件迁移（技术栈：Redis原生）

# 源Redis执行（生产环境建议在从库操作）
redis-cli -h 127.0.0.1 -p 6379 save  # 同步生成RDB文件
# 或者
redis-cli -h 127.0.0.1 -p 6379 bgsave # 后台生成RDB

# 查看RDB文件路径
redis-cli -h 127.0.0.1 -p 6379 config get dir
> 1) "dir"
> 2) "/var/lib/redis"

# 传输文件到目标服务器
scp /var/lib/redis/dump.rdb user@new_server:/data/redis/

# 目标服务器配置（redis.conf）
daemonize yes
dir /data/redis
dbfilename dump.rdb

# 重启目标Redis
systemctl restart redis-server

注意事项：

  • 停机时间=生成RDB时间+传输时间
  • 确保目标Redis版本 >= 源版本
  • 大数据集建议使用bgsave避免阻塞
  • 迁移后验证key数量：redis-cli dbsize

2.2 主从复制迁移（技术栈：Redis Replication）

# 目标Redis作为从库配置（目标服务器执行）
redis-cli -h new_host -p 6380 replicaof old_host 6379

# 查看同步状态（目标服务器）
redis-cli -h new_host -p 6380 info replication
# 输出应包含：
# role:slave
# master_host:old_host
# master_port:6379
# master_sync_in_progress:0
# master_sync_left_bytes:0

# 完成同步后解除主从关系
redis-cli -h new_host -p 6380 replicaof no one

进阶技巧：

  • 使用redis-cli --rdb获取实时RDB快照
  • 增量同步时注意repl-backlog-size配置
  • 网络不稳定时考虑中间代理层

2.3 集群迁移黑科技（技术栈：Redis Cluster）

# 添加新节点到集群
redis-cli --cluster add-node new_node:7000 existing_node:7000

# 重新分片（迁移数据）
redis-cli --cluster reshard existing_node:7000 \
    --cluster-from all \
    --cluster-to new_node_id \
    --cluster-slots 4096 \
    --cluster-yes

# 最终平衡集群
redis-cli --cluster rebalance existing_node:7000 \
    --cluster-weight new_node=2 \
    --cluster-use-empty-masters

避坑指南：

  • 每个节点至少预留10%内存用于迁移缓冲区
  • 迁移过程中监控cluster_state状态
  • 使用--cluster-replace替换故障节点

2.4 瑞士军刀：redis-shake工具（技术栈：阿里云开源工具）

# shake.conf 配置文件示例
source.type: cluster
source.address: 192.168.1.100:7000;192.168.1.101:7001
target.type: standalone
target.address: 10.0.0.200:6379
key_whitelist: "user:*|order:*"  # 只迁移特定前缀的key
parallel: 32                     # 并发线程数
rewrite: true                    # 覆盖目标已存在key

启动命令：

./redis-shake.linux -type=sync -conf=shake.conf

性能优化：

  • 调整batch_size参数（默认50）
  • 使用多个redis-shake实例并行迁移
  • 开启TLS加密传输

2.5 云服务商的秘密武器（技术栈：阿里云DTS）

虽然各云厂商的实现细节不同，但核心流程类似：

  1. 创建双向同步任务
  2. 配置白名单/黑名单
  3. 数据校验阶段
  4. 切换流量
  5. 同步追平后断开

三、迁移方案的选择矩阵

场景特征 推荐方案 预期耗时 风险等级
小数据集停机迁移 RDB文件迁移 分钟级 ★☆☆☆☆
跨版本升级 主从复制 小时级 ★★☆☆☆
集群扩容 Cluster Reshard 天级 ★★★☆☆
混合云迁移 redis-shake 小时级 ★★★★☆
生产环境无缝切换 云服务DTS+双写 天级 ★★☆☆☆

四、那些年我踩过的坑

案例1：大Key引发的血案 迁移200GB的Sorted Set时，单线程迁移导致超时。解决方案：

redis-cli -h source_host --bigkeys  # 提前识别大Key
redis-cli -h source_host scan 0 match large_key* count 1000
# 使用pipeline分批迁移
cat migrate_script.txt | redis-cli -h target_host --pipe

案例2：版本兼容的暗礁 从Redis 4迁移到6时发现Streams数据结构不兼容。通过版本验证脚本避免：

def check_version_compatibility(source_ver, target_ver):
    # 解析版本号逻辑...
    if source_ver > target_ver:
        raise Exception("目标版本必须 >= 源版本！")

五、迁移后的必修课

  1. 数据校验：使用redis-full-check工具
./redis-full-check -s "source_host:6379" -t "target_host:6380" -p 16
  1. 性能基准测试：
redis-benchmark -h target_host -p 6380 -c 100 -n 100000
  1. 监控预警配置：
# Prometheus配置示例
- job_name: 'redis'
  static_configs:
  - targets: ['target_host:9121']

六、技术延伸：关联技术解密

Redis持久化原理：

  • RDB的Copy-on-Write机制
  • AOF重写的管道优化
  • 混合持久化（Redis 4.0+）

集群分片算法：

  • 一致性哈希的实现细节
  • CRC16算法的槽位计算
  • Gossip协议的通信机制

七、终极总结

经过多次实战检验，我的迁移方法论可总结为：

  1. 事前：容量规划+兼容检查+备份回滚方案
  2. 事中：灰度迁移+实时监控+熔断机制
  3. 事后：数据校验+性能测试+观察期

记住，没有完美的迁移方案，只有最适合当前业务场景的方案。当遇到PB级数据迁移时，不妨采用分阶段迁移策略：

第一阶段：历史数据冷迁移（RDB）
第二阶段：增量数据热同步（主从复制）
第三阶段：业务流量切换验证（双写+校验）

希望这篇凝结实战经验的文章，能让你在Redis迁移之路上少走弯路。毕竟，在数据为王的时代，每一次成功的迁移都是对技术人最好的褒奖。