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

摘要

Redis 作为高性能的内存数据库，广泛应用于缓存、会话存储等场景。随着业务发展，Redis 数据库的迁移需求日益增多，可能涉及硬件升级、云服务切换、数据分片调整等。本文以一次真实的 Redis 迁移项目为例，详细阐述迁移前的评估与规划、迁移方案的制定与实施、迁移过程中的问题处理及迁移后的验证与优化，为开发者提供一套可复用的 Redis 迁移方法论。

一、迁移前的评估与规划

1.1 迁移目标明确

迁移前需明确迁移目标，包括但不限于：

• 硬件升级：从低配服务器迁移至高配服务器，提升性能。
• 云服务切换：从自建 Redis 迁移至云服务商提供的 Redis 服务（如 AWS ElastiCache、阿里云 Redis）。
• 数据分片调整：从单节点迁移至集群模式，解决数据容量瓶颈。
• 版本升级：从旧版 Redis 迁移至新版，获取新功能或性能优化。

本次迁移目标为从自建 Redis 5.0 单节点迁移至 Redis 6.2 集群模式，以解决数据容量瓶颈并提升性能。

1.2 数据量评估

评估当前 Redis 数据库的数据量，包括键值对数量、总内存占用、数据类型分布等。使用 INFO 命令获取关键指标：

redis-cli INFO | grep -E "db0|used_memory"

输出示例：

db0:keys=1000000,expires=0,avg_ttl=0
used_memory:8589934592

根据输出，当前数据库有 100 万个键值对，内存占用 8GB。

1.3 迁移影响分析

分析迁移对业务的影响，包括：

• 停机时间：是否可接受完全停机迁移，或需支持在线迁移。
• 数据一致性：迁移过程中如何保证数据不丢失、不重复。
• 性能影响：迁移期间对读写性能的影响。

本次迁移需支持在线迁移，停机时间控制在 5 分钟内，数据一致性要求强一致。

1.4 迁移工具选型

根据迁移目标选择合适的工具：

• redis-cli —rdb：适用于小数据量或完全停机迁移。
• Redis 集群迁移工具：如 redis-trib.rb（Redis 5 之前）或 redis-cli --cluster（Redis 5+）。
• 第三方工具：如 aof-to-rdb、redis-migrate-tool。

本次迁移选用 redis-cli --cluster 工具，支持 Redis 6.2 集群模式。

二、迁移方案的制定与实施

2.1 迁移步骤设计

设计迁移步骤，包括：

1. 源库备份：防止迁移失败导致数据丢失。
2. 目标集群搭建：配置 Redis 6.2 集群，包括节点数、分片策略。
3. 数据迁移：使用工具将数据从源库迁移至目标集群。
4. 应用切换：将应用连接从源库切换至目标集群。
5. 验证与优化：验证数据一致性，优化集群性能。

2.2 源库备份

使用 BGSAVE 命令备份源库数据：

redis-cli BGSAVE

备份文件默认保存在 dump.rdb，需拷贝至安全位置。

2.3 目标集群搭建

以 3 主 3 从的 Redis 6.2 集群为例：

1. 启动 6 个 Redis 实例，配置 cluster-enabled yes。
2. 使用 redis-cli --cluster create 创建集群：

   redis-cli --cluster create 192.168.1.1:7000 192.168.1.2:7001 \
   192.168.1.3:7002 192.168.1.4:7003 192.168.1.5:7004 192.168.1.6:7005 \
   --cluster-replicas 1

2.4 数据迁移

使用 redis-cli --cluster import 将数据从源库迁移至目标集群：

redis-cli --cluster import 192.168.1.1:7000 --from 192.168.1.10:6379 --cluster-copy

• --from：源库地址。
• --cluster-copy：在线迁移，不阻塞源库读写。

2.5 应用切换

修改应用配置，将 Redis 连接地址从源库切换至目标集群。使用连接池管理集群连接，避免频繁创建连接。

三、迁移过程中的问题处理

3.1 大键值对迁移失败

问题：迁移过程中，部分大键值对（如数 MB 的 Hash）迁移失败，报错 ERR big input。
原因：Redis 默认限制单个命令的字节数（client-query-buffer-limit）。
解决方案：

1. 调整源库和目标库的 client-query-buffer-limit：

   redis-cli CONFIG SET client-query-buffer-limit 100000000

2. 分片迁移大键值对，或使用 HSCAN/SSCAN 逐步迁移。

3.2 集群节点负载不均

问题：迁移后，部分节点负载过高，导致读写延迟增加。
原因：默认哈希槽分配不均，或数据访问模式不均。
解决方案：

1. 使用 redis-cli --cluster rebalance 重新平衡哈希槽：

   redis-cli --cluster rebalance 192.168.1.1:7000

2. 监控节点负载，调整 cluster-node-timeout 和 cluster-migrate-threshold。

四、迁移后的验证与优化

4.1 数据一致性验证

验证迁移后数据是否一致：

1. 随机抽样键值对，比较源库和目标集群的值。
2. 使用 redis-rdb-tools 分析 dump.rdb 和集群快照，统计键值对数量和内存占用。

4.2 性能优化

优化集群性能：

1. 调整 maxmemory 和 maxmemory-policy，避免内存溢出。
2. 配置 slowlog-log-slower-than 和 slowlog-max-len，监控慢查询。
3. 使用 redis-benchmark 测试集群吞吐量和延迟。

五、总结与建议

5.1 迁移总结

本次迁移成功将自建 Redis 5.0 单节点迁移至 Redis 6.2 集群模式，停机时间控制在 3 分钟内，数据一致性验证通过。

5.2 建议

1. 提前规划：充分评估数据量、迁移影响和工具选型。
2. 备份优先：迁移前务必备份源库数据。
3. 分步实施：先小规模测试，再全量迁移。
4. 监控与优化：迁移后持续监控集群性能，及时优化。

通过本次迁移，我们积累了 Redis 集群迁移的实战经验，为后续类似项目提供了参考。