记一次 Redis 数据库迁移：从规划到落地的全流程实践

一、迁移背景与目标

在业务快速发展的过程中，原 Redis 集群（单节点+哨兵模式）逐渐暴露出性能瓶颈：内存容量接近上限、高并发场景下响应延迟波动明显，且跨机房访问延迟较高。经评估，决定将数据迁移至新集群（Redis Cluster 模式），采用三主三从架构，部署于多可用区以提升容灾能力，同时扩容内存至原集群的 3 倍。迁移目标明确为：零数据丢失、服务中断时间控制在 5 分钟内、迁移后性能提升 30% 以上。

二、迁移前的关键规划

1. 兼容性评估

• 数据结构兼容性：原集群使用 Hash、List、ZSet 等结构，新集群需支持相同操作（如 HGETALL、LPUSH、ZRANGE），经测试 Redis Cluster 对这些命令的分布式处理无兼容性问题。
• 客户端兼容性：原业务使用 Jedis 2.9.0，需升级至支持 Cluster 的 Jedis 3.7.0，或改用 Lettuce（天然支持 Cluster）。测试发现 Jedis 3.7.0 的 JedisCluster 类可无缝兼容，但需修改连接池配置为集群模式。

2. 迁移工具选型

• 官方工具：redis-trib.rb（Redis 3.x）或 redis-cli --cluster（Redis 5+）支持集群创建与数据迁移，但需手动处理键分布，适合小规模迁移。
• 第三方工具：
  • RedisShake：支持全量+增量同步，可自定义键过滤规则，适合跨版本、跨模式迁移（如单机到集群）。
  • AWS DMS（若使用云服务）：支持 Redis 到 Redis 的迁移，但配置复杂且依赖云环境。
• 最终选择：RedisShake 2.2.1，因其支持断点续传、流量控制，且社区活跃度高。

3. 数据一致性保障

• 全量同步：通过 BGSAVE 生成 RDB 文件，确保初始数据完整。
• 增量同步：启用 Redis 的 AOF 日志，RedisShake 实时解析日志并同步至新集群。
• 校验机制：迁移后使用 redis-rdb-tools 对比新旧集群的键数量与样本数据，误差率需低于 0.01%。

三、迁移实施步骤

1. 环境准备

• 新集群部署：

  # 使用 redis-cli 创建集群（示例为 3 主 3 从）
  redis-cli --cluster create 10.0.1.1:6379 10.0.1.2:6379 10.0.1.3:6379 \
    10.0.2.1:6379 10.0.2.2:6379 10.0.2.3:6379 --cluster-replicas 1

• 网络配置：开放 6379（数据端口）、16379（集群总线端口），确保跨机房低延迟（<1ms）。

2. 全量+增量迁移

• 配置 RedisShake：

  [source]
  address = "10.0.0.1:6379"
  password = "old_password"
  [target]
  address = "10.0.1.1:6379"  # 集群任意节点
  password = "new_password"
  target_type = "cluster"
  [filter]
  db_filter = "0"  # 迁移 DB 0
  key_filter = ["user:*", "order:*"]  # 白名单过滤

• 启动迁移：

  ./redis-shake -conf=config.toml -type=sync

• 监控进度：通过 redis-shake-stats.log 查看同步延迟、键数量等指标。

3. 流量切换

• 灰度发布：
  1. 将 10% 的流量路由至新集群，观察错误率与响应时间。
  2. 无异常后逐步增加流量，每次间隔 10 分钟。
• 最终切换：

  # 修改 Nginx/HAProxy 配置，将所有请求指向新集群
  upstream redis_backend {
    server 10.0.1.1:6379;
    server 10.0.1.2:6379;
    server 10.0.1.3:6379;
  }

四、迁移后验证与优化

1. 数据一致性校验

• 键数量对比：

  # 原集群
  redis-cli -h 10.0.0.1 DBSIZE
  # 新集群
  redis-cli --cluster info 10.0.1.1:6379 | grep "keys"

• 样本数据抽检：随机选取 1000 个键，对比新旧集群的值是否一致。

2. 性能测试

• 基准测试：使用 redis-benchmark 模拟 500 并发请求：

  redis-benchmark -h 10.0.1.1 -t set,get -n 100000 -c 500

• 结果对比：迁移后 QPS 提升 35%，P99 延迟从 8ms 降至 5ms。

3. 优化措施

• 客户端连接池调整：将 maxTotal 从 50 提升至 200，maxIdle 从 10 提升至 50。
• 慢查询优化：通过 SLOWLOG GET 发现 HGETALL 操作耗时较高，改用 HSCAN 分批获取。

五、经验总结与建议

1. 预演的重要性：在测试环境模拟迁移全过程，提前发现客户端兼容性问题。
2. 滚动迁移策略：大集群迁移建议分批次进行（如按业务模块），降低风险。
3. 监控体系完善：迁移期间需实时监控新旧集群的内存、连接数、命令耗时等指标。
4. 回滚方案：准备旧集群的 RDB 备份，确保 30 分钟内可恢复服务。

此次迁移不仅解决了性能瓶颈，还通过集群模式提升了高可用性。后续计划引入 Redis 6.0 的 ACL 功能与客户端缓存，进一步优化架构。