一、迁移前的核心准备：评估与规划

1.1 业务场景与数据特征分析

Redis数据迁移需首先明确业务场景，例如电商的库存系统、社交平台的实时消息队列或金融的风控数据。不同场景对数据一致性、延迟和吞吐量的要求差异显著：

• 强一致性场景（如支付订单）：需采用同步复制或事务机制，确保迁移过程中数据零丢失。
• 最终一致性场景（如用户行为日志）：可通过异步复制或批量写入优化性能。

同时需评估数据规模：

• 小规模数据（GB级）：可直接使用redis-cli --rdb导出导入，或通过MIGRATE命令逐键迁移。
• 大规模数据（TB级）：需分片处理，结合SCAN命令迭代导出，避免单次操作阻塞主节点。

1.2 迁移目标与架构设计

明确迁移目标：

• 跨云迁移：需考虑网络延迟、带宽限制及数据加密（如TLS）。
• 版本升级：如从Redis 4.0迁移至6.2，需验证新版本兼容性（如模块、命令变更）。
• 架构优化：例如从单机迁移至集群模式，需重新设计分片策略。

架构设计要点：

• 读写分离：迁移期间保持读写分离，减少对主节点的影响。
• 灰度发布：先迁移非核心业务数据，验证稳定性后再迁移核心数据。

二、技术选型与工具对比

2.1 原生工具的适用场景

• MIGRATE命令：

  redis-cli -h source_host -p source_port --rdb migrate.rdb
  redis-cli -h target_host -p target_port --pipe < migrate.rdb

  适用于单键或小批量数据迁移，但无法处理大规模数据或集群环境。

• BGSAVE + SCAN组合：

  # 源节点执行BGSAVE生成RDB快照
  redis-cli -h source_host BGSAVE
  # 目标节点通过SCAN迭代导入
  redis-cli -h source_host --scan --pattern '*' | while read key; do
    redis-cli -h target_host SET "$key" "$(redis-cli -h source_host GET "$key")"
  done

  适合增量迁移，但需处理键过期时间（TTL）和数据类型转换（如Hash、List）。

2.2 第三方工具的优势

• RedisShake：

  • 支持全量+增量同步，断点续传。

  • 配置示例：

    [source]
    address = "source_host:6379"
    password = "your_password"
    [target]
    address = "target_host:6379"
    password = "your_password"
    [filter]
    db_filter = "0"  # 仅迁移DB0

  • 适用于跨版本、跨云迁移，但需注意资源消耗（CPU、内存）。

• Twemproxy代理迁移：
  通过修改代理配置，逐步将流量切换至新集群，实现零停机迁移。

三、迁移实施：分阶段操作指南

3.1 全量迁移阶段

1. 数据冻结：在低峰期（如凌晨2点）暂停写入，确保数据一致性。
2. 快照生成：

   redis-cli -h source_host SAVE  # 同步阻塞式快照
   # 或
   redis-cli -h source_host BGSAVE  # 异步非阻塞快照

3. 数据传输：使用scp或rsync将RDB文件传输至目标节点。
4. 数据加载：

   redis-cli -h target_host < /path/to/dump.rdb

3.2 增量同步阶段

1. 启用AOF持久化：在源节点开启AOF，记录迁移期间的写入操作。

   redis-cli -h source_host CONFIG SET appendonly yes

2. 实时同步：通过redis-cli --pipe或工具（如RedisShake）将AOF增量数据同步至目标节点。
3. 冲突解决：处理键冲突（如相同Key在不同节点被修改），可采用时间戳或版本号策略。

3.3 验证与切换

1. 数据校验：
   • 键数量对比：redis-cli -h source_host DBSIZE vs redis-cli -h target_host DBSIZE。
   • 抽样校验：随机抽取1000个键，验证值一致性。
2. 流量切换：
   • 修改DNS或负载均衡配置，逐步将流量导向目标节点。
   • 监控指标：延迟（LATENCY DOCTOR）、错误率（INFO中的rejected_connections）。

四、风险控制与应急预案

4.1 常见风险及应对

• 网络中断：
  • 启用断点续传（如RedisShake的resume_from_last_checkpoint）。
  • 压缩传输（如gzip压缩RDB文件）。
• 数据不一致：
  • 迁移前执行FLUSHDB清空目标DB，避免残留数据干扰。
  • 使用校验工具（如redis-rdb-tools）生成数据报告对比。
• 性能下降：
  • 迁移期间限制源节点写入速率（如CONFIG SET maxmemory-policy volatile-lru）。
  • 目标节点预分配内存（CONFIG SET maxmemory 100gb）。

4.2 回滚方案

1. 快速回滚：
   • 保留源节点数据至少24小时。
   • 修改DNS或代理配置，将流量切回源节点。
2. 数据修复：
   • 若目标节点数据损坏，重新执行全量迁移。
   • 若部分键丢失，从AOF或备份中恢复。

五、实战案例：电商库存系统迁移

5.1 业务背景

某电商平台的库存系统使用Redis集群存储商品库存，需从自建机房迁移至云上，同时升级至Redis 6.2以支持ACL权限控制。

5.2 迁移步骤

1. 架构设计：
   • 目标集群：3主3从，分片策略与源集群一致。
   • 迁移工具：RedisShake + 自定义脚本处理TTL。
2. 全量迁移：
   • 凌晨1点执行BGSAVE，生成RDB文件。
   • 通过scp传输至云上，加载至目标集群。
3. 增量同步：
   • 启用源集群AOF，通过RedisShake实时同步增量数据。
   • 自定义脚本处理TTL：

     def migrate_with_ttl(source, target):
         for key in source.scan_iter():
             ttl = source.ttl(key)
             value = source.get(key)
             target.setex(key, ttl, value)

4. 验证与切换：
   • 抽样校验10万个键，一致性达100%。
   • 逐步切换流量，监控延迟<2ms。

六、总结与建议

1. 测试环境先行：在生产环境迁移前，务必在测试环境验证工具和流程。
2. 监控与告警：迁移期间实时监控QPS、延迟、内存使用率。
3. 文档记录：详细记录迁移步骤、参数配置及问题解决方案。
4. 自动化脚本：将重复操作（如数据校验）封装为脚本，减少人为错误。

通过科学的规划、合适的技术选型及严格的风险控制，Redis业务数据迁移可实现高效、安全、零业务中断的目标。