Redis集群运维实战：从部署到排错的全流程指南
Redis集群在保证高可用和数据分片方面效果显著，但日常运维中很多新手容易在节点管理、故障转移和扩容缩容上踩坑。
本文从零开始，用可重现的命令和配置告诉你每一步该做什么、为什么这么做以及出错了怎么解决。
运维前必须准备的三样东西
- 操作系统与Redis版本：建议使用Linux（CentOS 7+ 或 Ubuntu 20.04+），Redis 6.x 或 7.x 均支持集群模式。查看版本命令：
redis-server --version- 集群基础概念：了解至少三个节点（每个节点再配一个从节点）才能形成可用集群。每个节点需要一个独立的端口（例如 7000~7005）。
- 必要的 Ruby 运行环境（仅旧版 redis-trib 需要）：新版
redis-cli --cluster已内置，无需额外安装。
三步完成集群状态检查与健康评估
1. 查看集群节点信息
登录任意集群节点，运行：
redis-cli -h 127.0.0.1 -p 7000 cluster nodes返回结果中重点看每个节点的 role（master/slave）、status（connected/fail）、slots 分配范围。
如果发现某个节点标记为 fail，需要立即排查。
2. 检查槽位分配是否完整
redis-cli -h 127.0.0.1 -p 7000 cluster slots正常返回会显示所有 16384 个哈希槽均被分配到可用的 master 节点。
如果出现 (error) CLUSTERDOWN The cluster is down，说明主节点丢失过多或网络分区。
3. 定期查看慢查询与连接数
redis-cli -h 127.0.0.1 -p 7000 slowlog get 10
redis-cli -h 127.0.0.1 -p 7000 info clients慢查询太多说明业务侧需要优化；
连接数超限则要调整 maxclients 或排查长连接泄漏。
集群节点扩容：加一个主节点并迁移槽位
假设新节点启动在 192.168.1.10:7006（master）和 7007（slave），操作分两步：
- 加入集群：
redis-cli -h 192.168.1.10 -p 7000 cluster meet 192.168.1.10 7006- 分配槽位（把其他master的一部分槽位挪过来）：
redis-cli -h 192.168.1.10 -p 7000 cluster reshard --cluster-from <源节点ID> --cluster-to <新节点ID> --cluster-slots 4096 --cluster-yes--cluster-slots 数量根据集群总槽数和机器负载调整，建议分批迁移避免瞬时流量爆发。
避坑指南：四个高频报错及解决
报错一：Node is not empty
新节点上如果已有数据（比如残留的RDB或AOF），再加入集群会失败。
解决方法：清空数据文件（flushall、删除dump.rdb），然后重启。
报错二：Cluster state is down
通常是因为主节点挂掉超过半数。
先用 cluster nodes 确认哪些主节点失效，如果失效节点能重启，直接启动后它会自动重新加入；
如果不能恢复，需要在集群中强制删除该节点：
redis-cli -h 正常节点IP -p 端口 cluster forget <失效节点ID>然后重新分配该节点原本负责的槽位。
报错三：MIGRATE socket error
迁移槽位时网络抖动或旧数据过大。
可以增大 cluster-node-timeout（默认15000ms），或者先手工将源节点的一部分 key 迁移走（MIGRATE 命令）避免大key阻塞。
报错四：SLAVE 复制滞后严重
在主从延迟超过 min-slaves-max-lag 时，会触发写入拒绝。
首先检查网络带宽和主库慢查询，其次可以考虑在从节点上开启 slave-serve-stale-data yes 允许提供旧数据（不推荐生产环境）。
效果验证：如何确认运维操作成功
场景一：新节点加入后
运行 cluster nodes 看到新节点 status 为 connected，并且 cluster slots 中槽位分布更新。
场景二：故障转移后
手工模拟主节点宕机：
redis-cli -h 192.168.1.10 -p 7000 debug segfault稍等几秒后，其他节点会自动选举从节点升级为主节点。
检查 cluster nodes，原主节点标记为 fail，新的主节点出现。
场景三：缩容后
先迁移槽位到其他master，再用 cluster forget 移除节点，最后手动停止进程。验证方法：同样用 cluster nodes 确认节点消失，槽位分布正确。
如果你正在处理 Redis 集群运维，建议先按本文步骤完整执行一遍，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。
掌握这些操作后，日常维护和紧急排障都会从容很多。
