Redis集群运维实战：从扩容缩容到数据迁移，我用redis-cli --cluster全搞定了
Redis集群运维实战：从扩容缩容到数据迁移的完整解决方案
凌晨三点，手机突然响起刺耳的告警铃声——Redis集群内存使用率突破90%。作为运维负责人，我经历过太多次这样的深夜紧急扩容。不同于单机Redis的简单重启，集群环境下的容量调整需要兼顾数据安全性与服务连续性。本文将分享如何用redis-cli --cluster命令体系化解决真实业务场景中的三大核心挑战：弹性扩缩容、数据平滑迁移和集群状态维护。
1. 集群扩容：应对业务洪峰的正确姿势
去年双十一大促期间，我们的商品详情页集群在流量暴涨前成功完成了横向扩展。不同于简单的节点添加，生产环境扩容需要遵循容量预判→节点部署→槽位平衡的标准化流程。
1.1 容量规划与节点准备
在添加新节点前，建议先通过CLUSTER INFO获取关键指标：
redis-cli -h 现有节点IP -p 端口 --cluster info重点关注以下输出项：
cluster_stats_messages_sent:112305 cluster_stats_messages_received:108472 used_memory_human:5.8G used_memory_peak_human:7.2G扩容决策矩阵：
| 指标 | 预警阈值 | 扩容建议 |
|---|---|---|
| 内存使用率 | >70% | 增加主节点 |
| 网络吞吐量 | >50MB/s | 优化拓扑或增节点 |
| 节点负载不均衡度 | >15% | rebalance操作 |
1.2 主从节点添加实战
添加主节点（以7007为例）：
redis-cli --cluster add-node 新节点IP:7007 现有集群节点IP:端口添加从节点并指定主节点：
redis-cli --cluster add-node 新节点IP:7008 现有集群节点IP:端口 \ --cluster-slave \ --cluster-master-id 主节点ID关键提示：获取节点ID可通过
CLUSTER NODES命令，输出结果的第一列即为节点唯一标识
1.3 槽位重分配策略
新主节点加入后需要手动分配槽位，推荐两种方式：
方案A：按比例迁移（适合均匀扩容）
redis-cli --cluster reshard 现有节点IP:端口 \ --cluster-from all \ --cluster-to 新节点ID \ --cluster-slots 4096 \ # 约占总槽位25% --cluster-yes方案B：指定源节点迁移（适合热点分离）
redis-cli --cluster reshard 现有节点IP:端口 \ --cluster-from 源节点ID \ --cluster-to 新节点ID \ --cluster-slots 2048 \ --cluster-pipeline 32 # 提升迁移吞吐量2. 安全缩容：业务低谷期的资源优化
某次版本迭代后，我们某个业务线的流量下降50%，及时缩容节省了40%的云主机成本。但缩容比扩容更易踩坑，需要严格遵循数据迁移→节点下线→配置清理的流程。
2.1 槽位迁移出待删除节点
检查目标节点槽位分布：
redis-cli --cluster check 待删除节点IP:端口迁移槽位到其他主节点（以迁移1000个槽位为例）：
redis-cli --cluster reshard 待删除节点IP:端口 \ --cluster-from 待删除节点ID \ --cluster-to 目标节点ID \ --cluster-slots 1000 \ --cluster-timeout 60000 # 超时时间设为60秒2.2 验证与节点删除
确认槽位已清空：
redis-cli -h 待删除节点IP -p 端口 cluster nodes | grep 该节点ID安全删除节点：
redis-cli --cluster del-node 集群任意节点IP:端口 待删除节点ID常见故障处理：
- 若遇到
[ERR] Node is not empty!错误，检查：- 是否还有残留槽位
- 是否有客户端长连接未断开
- 从节点是否已提前删除
3. 数据迁移：多场景下的跨集群搬运
从自建机房迁移到云平台时，我们开发了基于--cluster import的增量迁移方案。根据不同场景可选择以下三种模式：
3.1 完整数据迁移
适用于停机迁移场景：
redis-cli --cluster import 目标集群节点IP:端口 \ --cluster-from 源单节点IP:端口 \ --cluster-copy \ --cluster-replace3.2 增量数据同步
配合SCAN命令实现不停机迁移：
# 获取当前最大游标 redis-cli -h 源单节点IP -p 端口 scan 0 count 1000 # 分批导入 while read -r keys; do redis-cli -h 源单节点IP -p 端口 mget $keys | \ redis-cli -h 目标集群节点IP -p 端口 mset done < key_batch.txt3.3 异构集群间迁移
通过中间RDB文件转换：
# 源集群生成备份 redis-cli --cluster backup 源集群节点IP:端口 /backup_path # 恢复到目标集群 for rdb in /backup_path/*.rdb; do redis-cli -h 目标集群节点IP -p 端口 --pipe < $rdb done4. 集群维护：状态监控与故障处理
日常运维中，这些命令组合能解决90%的异常情况：
4.1 健康检查三板斧
快速状态检查：
redis-cli --cluster check 任意节点IP:端口 \ --cluster-search-multiple-owners槽位修复（当出现CRC16校验不一致时）：
redis-cli --cluster fix 问题节点IP:端口 \ --cluster-fix-with-unreachable-masters节点超时调整（网络抖动时特别有用）：
redis-cli --cluster set-timeout 任意节点IP:端口 5000 # 单位毫秒4.2 负载均衡最佳实践
动态调整节点权重：
redis-cli --cluster rebalance 任意节点IP:端口 \ --cluster-weight "节点1ID=1.5,节点2ID=0.8" \ --cluster-threshold 1.5 # 触发平衡的差异阈值性能优化参数：
| 参数 | 默认值 | 生产建议值 | 作用 |
|---|---|---|---|
| cluster-node-timeout | 15000 | 30000 | 节点通信超时 |
| pipeline | 10 | 32-64 | 批量操作key数 |
| migrate-timeout | 5000 | 60000 | 数据迁移超时 |
记得第一次做集群扩容时，因为没设置合理的pipeline参数，导致迁移过程持续了6个小时。后来发现适当增加--cluster-pipeline值能显著提升效率，但要注意网络带宽和节点负载的平衡。