1. 环境准备与目标设计
现状与目标
在开始 Redis 单节点迁移到集群 的过程前，需对当前单点的资源、数据规模、读写模式以及 SLA 有清晰的画像，明确迁移目标包括新的集群容量、主从结构、故障域以及可接受的停机时间。
本阶段的关键在于厘清数据分布、访问热区以及未来扩展性，建立可验证的目标指标如预期的 QPS、并发写入能力和数据可用性。
硬件与网络前提
确保新集群的节点具备稳定的网络带宽、低延迟和一致的时间源，硬件对比和网络拓扑直接影响集群的吞吐与稳定性。
网络分离、端口规则和防火墙策略需要事先规划，端口规划通常选取 7000 及以上区间，避免与现有服务冲突。
版本与依赖
统一的 Redis 版本与相容性是避免后续问题的基础，版本控制与依赖清单应覆盖集群所需特性（如集群模式、持久化策略等）。
此外，确保工具链就绪，例如 redis-cli、redis-tools、redis-shake 等，在迁移前已通过测试，确保可回滚渠道可用。
2. 从单节点迁移到集群的总体步骤
初始化集群节点与配置
第一步是准备好目标集群的节点信息和初始配置，在初始阶段禁用写入以避免迁移过程中的数据冲突。
随后在每个节点上配置 cluster-enabled yes、cluster-config-file nodes.conf、cluster-node-timeout 5000 等参数，并确保各节点之间的互信与端口连通性。
数据迁移策略与工具
单节点数据迁移到集群通常有两种主流方案：就地分片迁移（通过移动槽位实现数据再分布）和工具驱动迁移（如 redis-shake、手动分片）。迁移策略需结合数据热点、业务窗口和对在线可用性的要求。
若使用工具驱动迁移，需要事前设计数据一致性检查点、回滚方案与监控指引，确保在迁移过程中数据能够被正确验证与追踪。
# 示例：在新集群中创建 6 节点的集群，建议替换为实际节点地址
redis-cli --cluster create 192.168.1.101:7000 192.168.1.102:7000 192.168.1.103:7000 192.168.1.104:7000 192.168.1.105:7000 192.168.1.106:7000 --cluster-replicas 1
集群创建完成后，可以通过 RESHARD 工具将现有键槽逐步分配到新节点，实现数据的分布式持久化与高可用。
# 交互式 reshard 的简化示例（以实际节点信息执行即可）
redis-cli --cluster reshard 192.168.1.101:7000
# 按提示选择源节点、目标节点和槽位数量，完成后确认
3. 数据一致性与性能优化
该章节围绕从环境准备到数据一致性与性能优化的完整流程展开，确保迁移的可控性与稳定性。
一致性模型与风险控制
在 Redis 集群场景下，写入可能需要在主副本之间进行多次复制。WAIT 命令可让客户端等待指定数量的副本确认，从而提高数据的一致性保障。
迁移阶段需要持续监控复制延迟、槽位迁移状态，以及副本健康状况，风险点包括槽位错位、丢失槽、心跳失败等，需要有明确的告警与回滚路径。
性能调优与监控
性能优化覆盖配置层和运行时监控两端，重点关注 持久化策略、内存碎片、网络延迟等因素对吞吐与延迟的影响。
常用监控指标包括命中率、命中/失配比、QPS、延迟、内存使用、RDB/AOF 写入速率等。通过设定阈值与告警，能快速发现回退或瓶颈。
# 使用 WAIT 命令等待副本确认写入
redis-cli -p 7000 WAIT 2 1000
故障转移与容量规划
容量规划要结合业务峰值、热数据比例以及未来扩展趋势，预留冗余容量和节点是核心。
同时需要设计故障演练场景，包括主节点宕机后的自动故障转移、从节点接管，以及数据一致性验证的回滚方案，确保在真实环境中无缝切换。
