1. 集群方案选型为什么我最终选了Cluster模式先交代一下背景。我之前维护的一套系统Redis单节点扛了挺长时间但随着业务量上来问题开始暴露首先是内存不够用16G的实例光缓存数据就快撑爆了其次是单点风险太明显一次服务器重启整个服务直接雪崩所有请求穿透打到底层数据库差点把库打挂。那次故障之后我花了几个晚上研究Redis集群方案最终落地了官方Cluster模式并且完整地做了一轮功能验证。如果你也想搭Redis集群先把方案选型这一关想清楚。目前主流的Redis高可用方案就三种主从复制、哨兵模式Sentinel、官方Cluster集群。很多人一上来就纠结“到底选哪个”我的建议是看你的数据量和可用性要求。主从复制是最基础的方案一个主节点带着若干个从节点数据单向同步。它能解决读压力但主节点挂了之后需要人工手动切换而且切换期间服务是不可用的从节点只会干等。对可用性要求稍高的场景这方案基本不够看。哨兵模式是在主从复制基础上加了Sentinel进程来监控主节点状态主节点挂了能自动完成故障转移把某个从节点提升为主节点。它能解决高可用问题但它仍然是“一主多从”的架构数据总量受限于单节点的内存上限。如果你有几百G甚至上T的数据要缓存哨兵模式是扛不住的。Cluster模式则是把数据分片存储。整个集群里有多个主节点每个主节点负责一部分哈希槽slot总共16384个槽位通过CRC16算法对key计算后映射到具体槽位。这样数据被拆散到了多台机器上单机内存瓶颈被彻底打破同时每个主节点还可以配置从节点做主备。Cluster模式既解决了容量扩展问题又自带故障转移能力这也是我最终选它的核心理由。另外多提一句现在云厂商卖的Redis通常也是基于Cluster思路做的只是把运维细节封装好了。自己在物理机或云服务器上手动搭建最大的意义在于搞清楚背后的原理以后排查问题的时候能直接对应到具体环节。2. 环境准备与集群规划先把地基打牢2.1 拓扑规划6个节点是最小舒服配置Redis Cluster官方要求至少3个主节点才能形成完整集群为了高可用每个主节点至少配1个从节点所以6个节点3主3从是最常见的起步配置。如果机器资源紧张你甚至可以用6个端口在同一台机器上模拟但生产环境我强烈不建议这样做——一台物理机挂了所有节点一起挂集群失去意义。我这次用的是3台服务器每台上跑2个Redis实例分别映射不同端口既节省机器又保证基础的容错能力。具体规划如下服务器实例角色IP:端口用途说明服务器Amaster192.168.1.101:6379主节点1负责部分槽位服务器Aslave192.168.1.101:6380主节点1的从节点跨机冗余服务器Bmaster192.168.1.102:6379主节点2负责部分槽位服务器Bslave192.168.1.102:6380主节点2的从节点跨机冗余服务器Cmaster192.168.1.103:6379主节点3负责部分槽位服务器Cslave192.168.1.103:6380主节点3的从节点跨机冗余这个拓扑的关键设计在于同一台服务器的master和slave不能形成主备关系比如A上的6379和A上的6380如果做成主备等于是A这台机器挂了两个节点一起失联。所以规划时我会让每个主节点的从节点落在另一台机器上这样任意一台服务器宕机该服务器上的主节点都能在其他机器找到对应的从节点继续顶上来。2.2 版本选择别用太老的也别追最新Redis版本这块我踩过坑。早期用过一个比较老的3.x版本官方Cluster功能虽然存在但坑不少比如集群命令支持不够完整在线扩缩容的体验也比较差。后面我统一升级到了6.2系列稳定性和功能都算比较理想的折中。6.x版本有几个值得关注的改进一是多线程IO的引入虽然默认关闭但开启后对高并发场景有提升二是集群相关的命令和客户端库支持已经非常成熟主流语言的SDK都能直接对接Cluster模式三是对ACL权限控制的支持可以给不同应用分配不同权限。当然如果你是新项目直接用7.x也完全没问题我这边因为涉及业务兼容性没有激进升级。下载方式推荐去Redis官网拿源码包编译安装而不是图省事直接apt/yum安装。系统自带的版本往往偏旧且不一定能拿到最新的稳定特性。用源码编译其实也不复杂就几步命令的事# 下载并解压 wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar zxvf redis-6.2.14.tar.gz cd redis-6.2.14 # 编译安装指定安装目录 make make install PREFIX/usr/local/redis编译前需要确保系统有gcc和make工具缺少的话先安装yum install -y gcc gcc-c make # CentOS/RHEL系列 # 或者 apt install -y build-essential # Debian/Ubuntu系列编译过程中如果碰到jemalloc相关的报错通常是内存分配器的问题在make命令后面加MALLOClibc就能绕过make MALLOClibc2.3 目录规划和系统参数调整安装完成后目录结构我习惯这样组织方便后续维护和备份/usr/local/redis/ # Redis安装目录 /usr/local/redis/bin/ # 可执行文件 /etc/redis/6379.conf # 实例配置 /etc/redis/6380.conf # 实例配置 /data/redis/6379/ # AOF持久化文件目录 /data/redis/6380/ # AOF持久化文件目录 /data/redis/logs/ # 日志目录在启动集群前系统层面还有几个参数需要调整因为集群节点之间需要通过总线端口Cluster Bus通信且Redis的网络连接数可能会很高端口范围Cluster模式下每个节点除了对外服务的端口6379还会监听一个端口10000的集群总线端口即16379用于节点间的心跳检测、数据迁移等内部通信。所以安全组和防火墙不能只放行637916379也务必放行。文件描述符限制Redis作为高并发服务连接数可能非常大建议把/etc/security/limits.conf里的文件句柄数调高# /etc/security/limits.conf 中追加 * soft nofile 65535 * hard nofile 65535TCP内核参数如果遇到大量TIME_WAIT连接的问题可以适当调整内核参数但这个我是在压测验证阶段才遇到的后面专门讲。防火墙放行命令以firewalld为例firewall-cmd --permanent --add-port6379/tcp firewall-cmd --permanent --add-port16379/tcp firewall-cmd --reload这一层准备工作看似琐碎但是不做的话后面集群创建时会反复出现节点握手失败、cluster状态异常的问题排查起来很痛苦。3. 核心配置与节点启动每一行配置都要能说出为什么3.1 redis.conf里的关键配置项拆解每个Redis实例都需要一份独立的配置文件。这里我以6379端口的实例为例把关键配置项逐一说明大家抄作业的同时也理解每个参数的用途# /etc/redis/6379.conf port 6379 daemonize yes pidfile /var/run/redis_6379.pid logfile /data/redis/logs/redis_6379.log dir /data/redis/6379 # 集群开关 cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000 # 持久化配置 appendonly yes appendfsync everysec # 内存与淘汰策略 maxmemory 4gb maxmemory-policy allkeys-lru # 网络安全 bind 0.0.0.0 protected-mode yes requirepass MyRedisCluster2024 masterauth MyRedisCluster2024逐项解释一下核心参数cluster-enabled yes这个是总开关开启后Redis才会以Cluster模式运行。填no的话即使你后面用cluster相关命令也会报错提示集群模式未启用。cluster-config-file nodes-6379.conf这个文件由Redis自己维护记录的是当前节点视角下的集群拓扑信息包括哪些节点在线、槽位分配等。文件不要手动编辑Redis启动时会自动生成和更新。注意不同实例的这个文件名必须不同因为每个节点都有自己的视角。cluster-node-timeout 15000这个参数定义节点间通信的超时时间单位是毫秒。如果一个主节点超过这个时间没有响应集群会判定该节点故障并触发故障转移。设置太短容易误判网络抖动就触发切换设置太长则故障恢复慢。我最终稳定在了15秒兼顾了两者。appendonly yes和appendfsync everysec集群模式下的持久化建议开AOF每秒写一次。为什么集群了还要持久化因为节点挂了重启后如果能从本地恢复数据就不需要从主节点全量同步恢复速度会快很多对集群的冲击也更小。maxmemory 4gb限制每个实例最大内存。配合allkeys-lru淘汰策略保证在内存满的时候不会因为无法写入而拖垮整个集群。这块需要根据实际机器内存合理规划我建议给操作系统的剩余内存和redis的持久化磁盘IO留出余量不要顶满。requirepass和masterauth这是最容易忽略的地方。集群模式下主从节点之间也需要做同步从节点Promote为主节点后要用masterauth中配置的密码去连接新的主节点。如果只设置了requirepass而不设置masterauth主从切换或者重新建立复制关系时从节点会因为认证失败而一直无法同步数据。3.2 多实例部署时注意端口和目录隔离如果一台机器上跑多个Redis实例比如我这里的6379和6380第二份配置和第一份的区别主要是这些# /etc/redis/6380.conf port 6380 pidfile /var/run/redis_6380.pid logfile /data/redis/logs/redis_6380.log dir /data/redis/6380 cluster-config-file nodes-6380.conf其余参数保持一致即可不需要额外改动。这里容易出问题的是dir目录如果两个实例共用同一个持久化目录AOF文件和RDB文件会互相覆盖数据会出大乱子。这个我在初期搭建多实例时确实踩过后来强制约定“一个实例一个目录”再没出过问题。3.3 启动节点并确认集群模式生效配置文件写好后逐个启动各节点/usr/local/redis/bin/redis-server /etc/redis/6379.conf /usr/local/redis/bin/redis-server /etc/redis/6380.conf启动后用redis-cli进入实例执行cluster info看看状态/usr/local/redis/bin/redis-cli -p 6379 -a MyRedisCluster2024 127.0.0.1:6379 cluster info cluster_state:fail cluster_slots_assigned:0 cluster_slots_ok:0 cluster_known_nodes:1 cluster_size:0这个时候集群状态是fail不用慌因为还没把各个节点关联起来节点数也只是自己一个槽位分配为0。确认集群模式已经开启后接下来进入建集群的关键步骤。重要提示启动命令如果用了daemonize yesRedis会以守护进程在后台运行记得看日志确认正常起来。如果启动报错第一步一定是看日志文件把logfile里的内容截图下来对照排查不要瞎猜。4. 集群创建与各项验证从初始化到故障演练4.1 一条命令完成集群初始化Redis官方提供了redis-cli --cluster create命令来创建集群这个命令会自动完成节点握手和槽位分配非常方便。执行方式如下/usr/local/redis/bin/redis-cli --cluster create \ 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 \ 192.168.1.101:6380 192.168.1.102:6380 192.168.1.103:6380 \ --cluster-replicas 1 \ -a MyRedisCluster2024--cluster-replicas 1的含义是每个主节点配置1个从节点。命令执行后redis-cli会先检查节点状态然后给出一个槽位分配方案会显示类似这样的计划 Performing hash slots allocation on 6 nodes... Master[0] - Slots 0 - 5460 Master[1] - Slots 5461 - 10922 Master[2] - Slots 10923 - 16383 Adding replica 192.168.1.102:6380 to 192.168.1.101:6379 Adding replica 192.168.1.103:6380 to 192.168.1.102:6379 Adding replica 192.168.1.101:6380 to 192.168.1.103:6379注意它默认分配的从节点是比较合理的——这里可以看到101的从节点在102上102的从节点在103上103的从节点在101上每个从节点都和主节点不在同一台机器这正是我前面规划的跨机冗余。命令中间会询问Can I set the above configuration? (type yes to accept),这时候输入yes回车集群就开始握手并分配槽位。成功后会看到“All 16384 slots covered”的提示说明整个集群已经健康运行[OK] All 16384 slots covered.4.2 用cluster info和cluster nodes验证集群状态集群建好后第一件事是确认集群状态。连到任意一个节点执行127.0.0.1:6379 cluster info cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3重点看几个字段cluster_state:ok集群处于正常状态。如果是fail说明槽位不完整或有节点不可达。cluster_slots_assigned:16384全部16384个槽位都已分配。cluster_known_nodes:6集群已知节点数为6个。cluster_size:3集群主节点数量为3。再执行cluster nodes能看到完整的节点拓扑和角色信息127.0.0.1:6379 cluster nodes输出会展示每个节点的ID、IP:端口、角色master或slave、负责的槽位范围以及主从绑定关系。比如看到类似这样的行说明该节点是主节点且连接正常xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 192.168.1.101:637916379 myself,master - 0 0 1 connected 0-5460和从节点yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy 192.168.1.102:638016380 slave zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz 0 0 1 connected注意这里的16379就是前面的集群总线端口每个节点后面的端口号是它的总线端口不是业务端口。看到这些信息基本就能确认集群拓扑是符合预期的。4.3 数据读写验证搞懂CRC16槽位计算集群状态OK了接下来就是验证读写链路。Cluster模式下客户端连接任意节点如果key对应的槽位不在当前节点上节点会返回MOVED重定向错误客户端库会自行处理跳转。我们先手动验证一下这个机制能正常工作。先在一个主节点上写入数据127.0.0.1:6379 set user:1001 zhangsan OK 127.0.0.1:6379 get user:1001 zhangsan接着在另一个主节点上读取同一个key看看会发生什么127.0.0.1:102:6379 get user:1001 (error) MOVED 10439 192.168.1.101:6379返回的MOVED信息表示keyuser:1001对应的槽位是10439这个槽位在192.168.1.101:6379节点上。这说明集群的数据路由逻辑正常工作。正常情况下我们用的客户端SDK比如Java的Jedis、LettucePython的redis-py都会自动处理MOVED指令对应用层是透明的但如果用的是redis-cli需要加-c参数开启集群模式否则会直接报MOVED错误/usr/local/redis/bin/redis-cli -c -p 6379 -a MyRedisCluster2024-c参数让redis-cli自动跟随节点的重定向指示这样跨节点读写就不用手动指定了。关于槽位计算可以顺手做个验证。Redis Cluster用CRC16算法对key取CRC16值然后对16384取模得到槽位号。比如上面的user:1001落到槽位10439就是这个计算的结果。这个计算过程不用自己实现客户端库都帮你做了但理解这个概念有助于排查为什么某些key会落在某个节点上。4.4 故障转移验证手动关一个主节点集群的高可用能力不能停留在“理论上有”这个层面必须实操验证。我的验证方法是直接模拟主节点宕机观察集群是否能在阈值时间内自动完成故障转移。选定192.168.1.101:6379这个主节点把它直接停掉/usr/local/redis/bin/redis-cli -p 6379 -a MyRedisCluster2024 shutdown nosave然后观察集群日志和节点状态。正常情况下经过cluster-node-timeout我设置的15秒后集群会把这个主节点标记为fail并触发故障转移——它对应的从节点我这里是192.168.1.102:6380会被提升为新的主节点。用cluster nodes查看集群状态127.0.0.1:102:6379 cluster nodes会看到原本的从节点角色变成了master而且接管了原主节点负责的槽位。这说明自动故障转移成功。整个过程大概20秒左右符合预期。验证完毕后再把原来的主节点恢复启动。这里有个细节需要注意它启动后不会立刻恢复成主节点而是作为新的从节点挂到当前的主节点下面重新开始数据复制。这个行为是集群自动处理的对上层应用完全透明。如果你在生产环境做类似的故障演练建议在业务低峰期进行并且提前通知相关团队。虽然故障转移对客户端基本无感知但节点重启的瞬间连接池建连会有短暂的耗时波动。4.5 在线扩缩容水平扩展不是说说而已集群搭建好验证了基本功能和高可用性还不够还要验证集群的扩展能力。Redis Cluster支持在线增加节点和删除节点整个过程不需要停机。新增一个节点时我习惯用一个独立的端口比如在服务器A上再起一个6381端口实例配置文件和前面一样只是端口和目录不同。启动后先把它加入到集群/usr/local/redis/bin/redis-cli --cluster add-node \ 192.168.1.101:6381 \ 192.168.1.101:6379 \ -a MyRedisCluster2024这个命令会以6379作为“介绍人”把6381节点加入集群。加入后新节点默认是不负责槽位的需要手动执行reshard来分配槽位/usr/local/redis/bin/redis-cli --cluster reshard \ 192.168.1.101:6379 \ --cluster-from all \ --cluster-to 新节点ID \ --cluster-slots 4096 \ -a MyRedisCluster2024因为集群总共16384个槽位原来3个主节点平均分配新增一个主节点后理想情况是每个节点4096个槽位。所以这里把4096个槽位从所有老节点迁移到新节点。执行过程中会有交互式确认跟着提示走就行。迁移完成后再用cluster nodes查看确认新节点已经接管了部分槽位且原有节点各自的槽位数减少了。这就是水平扩容的完整过程。4.6 压测验证让数据说话最后一项验证是压测。Redis自带redis-benchmark工具可以方便地模拟并发读写。我用它跑了两个场景单节点基准压测和集群压测对比结果来确认集群模式下的性能损耗在可接受范围。单节点压测/usr/local/redis/bin/redis-benchmark -h 192.168.1.101 -p 6379 \ -a MyRedisCluster2024 -c 200 -n 1000000 -t set,get -d 100集群压测需要用集群模式/usr/local/redis/bin/redis-benchmark -h 192.168.1.101 -p 6379 \ -a MyRedisCluster2024 -c 200 -n 1000000 -t set,get -d 100 --cluster实测下来3主3从的集群在并发200、百万级操作请求下QPS轻松突破10万响应时间P99在个位数毫秒级别。和生产单节点相比因为数据分散到了多个节点性能不降反升。不过这里有个点要注意redis-benchmark的--cluster模式依赖一个与集群节点的交互能力如果你的安装在老版本上可能不支持该参数需要手动指定不同的节点来模拟请求分散效果。压测结束后记得查看机器的CPU、内存和网络负载确认集群的瓶颈在哪里。通常瓶颈会出现在网卡或者CPU单核上因为Redis是单线程模型IO多线程默认没开启的话多核利用不充分。如果CPU还没跑满但网卡先满了就该考虑扩容机器或者增加网卡带宽了。5. 常见问题与排查技巧实录5.1 集群状态卡在fail先查槽位分配和节点握手cluster_state:fail是最常见的集群异常状态。原因通常有两类一是槽位没有完全覆盖上面提到刚创建集群时是正常的0/16384二是集群中存在不可达节点。排查思路是这样的先看cluster_nodes输出找到标记为disconnected的节点确认它的IP:端口是否还能ping通如果网络没问题再看集群总线端口端口10000是否被防火墙拦截。我之前排查过一个案例业务端口6379通了但总线端口16379没放行节点之间无法通信集群一直报fail。处理方式很简单放行总线端口后再使用cluster meet命令让节点重新握手等几秒后集群状态会自动恢复。5.2 主从同步失败八成是masterauth的锅用着用着发现某个从节点数据一直不同步查看复制状态127.0.0.1:6380 info replication如果master_link_status:down并且日志里反复出现MASTER aborted replication with an error: NOAUTH Authentication required那基本可以确认是masterauth没配置或者密码不对。上面配置时我强调过requirepass和masterauth必须同时设置就是防这个坑。处理方法是在从节点的配置文件里补上正确的masterauth重启从节点实例复制关系就会自动恢复。生产环境还有一个隐蔽场景业务方修改了集群密码结果只改了requirepass忘了同步改masterauth导致整个集群的复制链路全部断裂。这个坑我见人踩过所以集群密码变更的checklist里一定要包含这两项。5.3 key分布不均匀导致热点问题集群模式下所有key被平均分布到16384个槽位理论上数据是均衡的。但实际业务中某些key的访问频率可能远高于其他key造成单节点热点拖累整个集群吞吐量。比如一个秒杀场景下的热卖商品ID所有请求都打向同一个key对应的槽位和节点负载就特别高。解决办法是给这些热点key加随机后缀把请求分散到不同的key上比如product:1001拆成product:1001:0到product:1001:9十个key这样它们的槽位散落到不同节点压力自然分散。代价是应用层需要多维护一层映射关系读的时候要把所有后缀key都查一遍。这个方案虽然土但非常有效是处理key热点问题的常用手段。另外Redis Cluster还支持hash tag机制可以让某些key强制落在同一个槽位。它的用法是如果key中含有{}Redis只对花括号内部的内容计算CRC16。比如user:{1001}:profile和user:{1001}:orders这两个key会落在同一个槽位。这在需要批量操作多个key比如MGET时非常有用因为Cluster模式下跨槽位的多key操作是不被保证原子性的而同一个槽位内可以。5.4 内存淘汰策略没设好导致写失败如果你在配置里没有设置maxmemory和maxmemory-policyRedis默认情况下内存满了就直接拒绝写入报错OOM command not allowed when used memory maxmemory。集群模式下这个问题的危害更大因为单个节点满了该节点负责的槽位无法写入等于整个集群的部分写入功能降级。我在配置里已经给出了推荐maxmemory 4gballkeys-lru。前者是内存水位后者是淘汰策略表示内存满时优先淘汰最近最少使用的key。这里有一个取舍allkeys-lru会淘汰所有key包括一些可能还需要的数据如果需要更精细的控制可以改用volatile-lru只淘汰设置了过期时间的key。但前提是你的业务key绝大多数都设置了TTL不然会导致内存无法释放。我这边业务上大量key本来就有过期时间所以用volatile-lru会更合适但为了安全兜底最终选了allkeys-lru至少保证写入一直可用。5.5 大量TIME_WAIT连接导致端口耗尽压测时遇到一个有趣的问题一段时间后客户端连接Redis报错Cannot assign requested address。排查后发现是客户端机器的TIME_WAIT状态连接堆积太多导致端口被耗尽了。这是因为高并发下客户端每次连接Redis后快速断开大量的TCP连接进入TIME_WAIT状态要等2MSL通常60秒才能释放。压测期间QPS高这个堆积速度远超释放速度。解决办法有几个方向客户端使用连接池不要每次请求都新建连接。大部分语言SDK默认维护连接池确保池大小设置合理即可。调整客户端的TCP参数允许端口复用sysctl -w net.ipv4.tcp_tw_reuse1缩短TIME_WAIT等待时间sysctl -w net.ipv4.tcp_fin_timeout15这是压测场景下的常用手段。在正式环境重点是确保连接池配置正确而不是无脑调内核参数。5.6 常见问题速查表现象可能原因排查与处理集群状态为fail槽位未分配完整、节点不可达执行cluster nodes检查断连节点确认总线和业务端口都放通从节点数据不同步masterauth密码不匹配检查info replication确认master_link_status修正masterauth后重启写操作报MOVED错误客户端未启用集群模式客户端连接时开启集群模式redis-cli加-c内存满了无法写入maxmemory和淘汰策略未配置设置合理的maxmemory和maxmemory-policy连接数过多触发TIME_WAIT客户端未使用连接池优化连接池配置必要时调内核TCP参数故障转移不触发cluster-node-timeout设置过大根据业务容忍度适当调小该参数扩容后槽位不均衡reshard操作不完整重新执行reshard合理分配迁移槽位数6. 个人经验与扩展建议集群搭建完成并全部验证通过后我最大的体会是搭建本身并不难真正花时间的是理解集群机制、设计合理的拓扑以及把故障转移、扩缩容这些运维动作都演练到位。有几个点想单独再强调一下。第一集群上线前一定要把监控做起来。我这边用Prometheus redis_exporter采集每个集群节点的指标包括内存使用率、命中率、主从复制延迟、槽位分布情况等。一旦某个节点的内存增长曲线异常或者复制延迟持续拉高监控告警会先于用户反馈发现问题。集群不是搭完就万事大吉后续的日常巡检才是保障稳定性的关键。第二备份策略不能因为集群就放松。有些朋友觉得“集群里每个主节点都有从节点数据肯定安全”这种想法很危险。从节点同步的数据是实时的但如果发生逻辑错误比如误执行了FLUSHALL、业务代码批量删除错误操作会立刻被复制到所有从节点集群的冗余保护是防不住这种人为事故的。所以集群模式下依然要定期做RDB备份而且备份要存放在独立的存储上不能和Redis节点在同一台机器。第三升级和运维操作要有预案。比如Redis大版本升级我一般会先在测试集群上完整跑一遍验证流程确认兼容性后再动生产。扩缩容操作尽量在业务低峰期执行并且提前确认客户端SDK支持集群模式避免因为客户端不支持MOVED重定向导致线上故障。后续如果你们的Redis集群规模再往上走还可以考虑引入官方提供的Redis Cluster Managerredis-cli --cluster之外的工具链比如一些图形化管理面板能直观看到每个节点的槽位和主从关系。但所有自动化和工具都建立在基础原理之上把这台集群彻底搞透后面再怎么变都不慌。 Redis Cluster集群搭建实战：从选型到故障演练
1. 集群方案选型为什么我最终选了Cluster模式先交代一下背景。我之前维护的一套系统Redis单节点扛了挺长时间但随着业务量上来问题开始暴露首先是内存不够用16G的实例光缓存数据就快撑爆了其次是单点风险太明显一次服务器重启整个服务直接雪崩所有请求穿透打到底层数据库差点把库打挂。那次故障之后我花了几个晚上研究Redis集群方案最终落地了官方Cluster模式并且完整地做了一轮功能验证。如果你也想搭Redis集群先把方案选型这一关想清楚。目前主流的Redis高可用方案就三种主从复制、哨兵模式Sentinel、官方Cluster集群。很多人一上来就纠结“到底选哪个”我的建议是看你的数据量和可用性要求。主从复制是最基础的方案一个主节点带着若干个从节点数据单向同步。它能解决读压力但主节点挂了之后需要人工手动切换而且切换期间服务是不可用的从节点只会干等。对可用性要求稍高的场景这方案基本不够看。哨兵模式是在主从复制基础上加了Sentinel进程来监控主节点状态主节点挂了能自动完成故障转移把某个从节点提升为主节点。它能解决高可用问题但它仍然是“一主多从”的架构数据总量受限于单节点的内存上限。如果你有几百G甚至上T的数据要缓存哨兵模式是扛不住的。Cluster模式则是把数据分片存储。整个集群里有多个主节点每个主节点负责一部分哈希槽slot总共16384个槽位通过CRC16算法对key计算后映射到具体槽位。这样数据被拆散到了多台机器上单机内存瓶颈被彻底打破同时每个主节点还可以配置从节点做主备。Cluster模式既解决了容量扩展问题又自带故障转移能力这也是我最终选它的核心理由。另外多提一句现在云厂商卖的Redis通常也是基于Cluster思路做的只是把运维细节封装好了。自己在物理机或云服务器上手动搭建最大的意义在于搞清楚背后的原理以后排查问题的时候能直接对应到具体环节。2. 环境准备与集群规划先把地基打牢2.1 拓扑规划6个节点是最小舒服配置Redis Cluster官方要求至少3个主节点才能形成完整集群为了高可用每个主节点至少配1个从节点所以6个节点3主3从是最常见的起步配置。如果机器资源紧张你甚至可以用6个端口在同一台机器上模拟但生产环境我强烈不建议这样做——一台物理机挂了所有节点一起挂集群失去意义。我这次用的是3台服务器每台上跑2个Redis实例分别映射不同端口既节省机器又保证基础的容错能力。具体规划如下服务器实例角色IP:端口用途说明服务器Amaster192.168.1.101:6379主节点1负责部分槽位服务器Aslave192.168.1.101:6380主节点1的从节点跨机冗余服务器Bmaster192.168.1.102:6379主节点2负责部分槽位服务器Bslave192.168.1.102:6380主节点2的从节点跨机冗余服务器Cmaster192.168.1.103:6379主节点3负责部分槽位服务器Cslave192.168.1.103:6380主节点3的从节点跨机冗余这个拓扑的关键设计在于同一台服务器的master和slave不能形成主备关系比如A上的6379和A上的6380如果做成主备等于是A这台机器挂了两个节点一起失联。所以规划时我会让每个主节点的从节点落在另一台机器上这样任意一台服务器宕机该服务器上的主节点都能在其他机器找到对应的从节点继续顶上来。2.2 版本选择别用太老的也别追最新Redis版本这块我踩过坑。早期用过一个比较老的3.x版本官方Cluster功能虽然存在但坑不少比如集群命令支持不够完整在线扩缩容的体验也比较差。后面我统一升级到了6.2系列稳定性和功能都算比较理想的折中。6.x版本有几个值得关注的改进一是多线程IO的引入虽然默认关闭但开启后对高并发场景有提升二是集群相关的命令和客户端库支持已经非常成熟主流语言的SDK都能直接对接Cluster模式三是对ACL权限控制的支持可以给不同应用分配不同权限。当然如果你是新项目直接用7.x也完全没问题我这边因为涉及业务兼容性没有激进升级。下载方式推荐去Redis官网拿源码包编译安装而不是图省事直接apt/yum安装。系统自带的版本往往偏旧且不一定能拿到最新的稳定特性。用源码编译其实也不复杂就几步命令的事# 下载并解压 wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar zxvf redis-6.2.14.tar.gz cd redis-6.2.14 # 编译安装指定安装目录 make make install PREFIX/usr/local/redis编译前需要确保系统有gcc和make工具缺少的话先安装yum install -y gcc gcc-c make # CentOS/RHEL系列 # 或者 apt install -y build-essential # Debian/Ubuntu系列编译过程中如果碰到jemalloc相关的报错通常是内存分配器的问题在make命令后面加MALLOClibc就能绕过make MALLOClibc2.3 目录规划和系统参数调整安装完成后目录结构我习惯这样组织方便后续维护和备份/usr/local/redis/ # Redis安装目录 /usr/local/redis/bin/ # 可执行文件 /etc/redis/6379.conf # 实例配置 /etc/redis/6380.conf # 实例配置 /data/redis/6379/ # AOF持久化文件目录 /data/redis/6380/ # AOF持久化文件目录 /data/redis/logs/ # 日志目录在启动集群前系统层面还有几个参数需要调整因为集群节点之间需要通过总线端口Cluster Bus通信且Redis的网络连接数可能会很高端口范围Cluster模式下每个节点除了对外服务的端口6379还会监听一个端口10000的集群总线端口即16379用于节点间的心跳检测、数据迁移等内部通信。所以安全组和防火墙不能只放行637916379也务必放行。文件描述符限制Redis作为高并发服务连接数可能非常大建议把/etc/security/limits.conf里的文件句柄数调高# /etc/security/limits.conf 中追加 * soft nofile 65535 * hard nofile 65535TCP内核参数如果遇到大量TIME_WAIT连接的问题可以适当调整内核参数但这个我是在压测验证阶段才遇到的后面专门讲。防火墙放行命令以firewalld为例firewall-cmd --permanent --add-port6379/tcp firewall-cmd --permanent --add-port16379/tcp firewall-cmd --reload这一层准备工作看似琐碎但是不做的话后面集群创建时会反复出现节点握手失败、cluster状态异常的问题排查起来很痛苦。3. 核心配置与节点启动每一行配置都要能说出为什么3.1 redis.conf里的关键配置项拆解每个Redis实例都需要一份独立的配置文件。这里我以6379端口的实例为例把关键配置项逐一说明大家抄作业的同时也理解每个参数的用途# /etc/redis/6379.conf port 6379 daemonize yes pidfile /var/run/redis_6379.pid logfile /data/redis/logs/redis_6379.log dir /data/redis/6379 # 集群开关 cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 15000 # 持久化配置 appendonly yes appendfsync everysec # 内存与淘汰策略 maxmemory 4gb maxmemory-policy allkeys-lru # 网络安全 bind 0.0.0.0 protected-mode yes requirepass MyRedisCluster2024 masterauth MyRedisCluster2024逐项解释一下核心参数cluster-enabled yes这个是总开关开启后Redis才会以Cluster模式运行。填no的话即使你后面用cluster相关命令也会报错提示集群模式未启用。cluster-config-file nodes-6379.conf这个文件由Redis自己维护记录的是当前节点视角下的集群拓扑信息包括哪些节点在线、槽位分配等。文件不要手动编辑Redis启动时会自动生成和更新。注意不同实例的这个文件名必须不同因为每个节点都有自己的视角。cluster-node-timeout 15000这个参数定义节点间通信的超时时间单位是毫秒。如果一个主节点超过这个时间没有响应集群会判定该节点故障并触发故障转移。设置太短容易误判网络抖动就触发切换设置太长则故障恢复慢。我最终稳定在了15秒兼顾了两者。appendonly yes和appendfsync everysec集群模式下的持久化建议开AOF每秒写一次。为什么集群了还要持久化因为节点挂了重启后如果能从本地恢复数据就不需要从主节点全量同步恢复速度会快很多对集群的冲击也更小。maxmemory 4gb限制每个实例最大内存。配合allkeys-lru淘汰策略保证在内存满的时候不会因为无法写入而拖垮整个集群。这块需要根据实际机器内存合理规划我建议给操作系统的剩余内存和redis的持久化磁盘IO留出余量不要顶满。requirepass和masterauth这是最容易忽略的地方。集群模式下主从节点之间也需要做同步从节点Promote为主节点后要用masterauth中配置的密码去连接新的主节点。如果只设置了requirepass而不设置masterauth主从切换或者重新建立复制关系时从节点会因为认证失败而一直无法同步数据。3.2 多实例部署时注意端口和目录隔离如果一台机器上跑多个Redis实例比如我这里的6379和6380第二份配置和第一份的区别主要是这些# /etc/redis/6380.conf port 6380 pidfile /var/run/redis_6380.pid logfile /data/redis/logs/redis_6380.log dir /data/redis/6380 cluster-config-file nodes-6380.conf其余参数保持一致即可不需要额外改动。这里容易出问题的是dir目录如果两个实例共用同一个持久化目录AOF文件和RDB文件会互相覆盖数据会出大乱子。这个我在初期搭建多实例时确实踩过后来强制约定“一个实例一个目录”再没出过问题。3.3 启动节点并确认集群模式生效配置文件写好后逐个启动各节点/usr/local/redis/bin/redis-server /etc/redis/6379.conf /usr/local/redis/bin/redis-server /etc/redis/6380.conf启动后用redis-cli进入实例执行cluster info看看状态/usr/local/redis/bin/redis-cli -p 6379 -a MyRedisCluster2024 127.0.0.1:6379 cluster info cluster_state:fail cluster_slots_assigned:0 cluster_slots_ok:0 cluster_known_nodes:1 cluster_size:0这个时候集群状态是fail不用慌因为还没把各个节点关联起来节点数也只是自己一个槽位分配为0。确认集群模式已经开启后接下来进入建集群的关键步骤。重要提示启动命令如果用了daemonize yesRedis会以守护进程在后台运行记得看日志确认正常起来。如果启动报错第一步一定是看日志文件把logfile里的内容截图下来对照排查不要瞎猜。4. 集群创建与各项验证从初始化到故障演练4.1 一条命令完成集群初始化Redis官方提供了redis-cli --cluster create命令来创建集群这个命令会自动完成节点握手和槽位分配非常方便。执行方式如下/usr/local/redis/bin/redis-cli --cluster create \ 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 \ 192.168.1.101:6380 192.168.1.102:6380 192.168.1.103:6380 \ --cluster-replicas 1 \ -a MyRedisCluster2024--cluster-replicas 1的含义是每个主节点配置1个从节点。命令执行后redis-cli会先检查节点状态然后给出一个槽位分配方案会显示类似这样的计划 Performing hash slots allocation on 6 nodes... Master[0] - Slots 0 - 5460 Master[1] - Slots 5461 - 10922 Master[2] - Slots 10923 - 16383 Adding replica 192.168.1.102:6380 to 192.168.1.101:6379 Adding replica 192.168.1.103:6380 to 192.168.1.102:6379 Adding replica 192.168.1.101:6380 to 192.168.1.103:6379注意它默认分配的从节点是比较合理的——这里可以看到101的从节点在102上102的从节点在103上103的从节点在101上每个从节点都和主节点不在同一台机器这正是我前面规划的跨机冗余。命令中间会询问Can I set the above configuration? (type yes to accept),这时候输入yes回车集群就开始握手并分配槽位。成功后会看到“All 16384 slots covered”的提示说明整个集群已经健康运行[OK] All 16384 slots covered.4.2 用cluster info和cluster nodes验证集群状态集群建好后第一件事是确认集群状态。连到任意一个节点执行127.0.0.1:6379 cluster info cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3重点看几个字段cluster_state:ok集群处于正常状态。如果是fail说明槽位不完整或有节点不可达。cluster_slots_assigned:16384全部16384个槽位都已分配。cluster_known_nodes:6集群已知节点数为6个。cluster_size:3集群主节点数量为3。再执行cluster nodes能看到完整的节点拓扑和角色信息127.0.0.1:6379 cluster nodes输出会展示每个节点的ID、IP:端口、角色master或slave、负责的槽位范围以及主从绑定关系。比如看到类似这样的行说明该节点是主节点且连接正常xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 192.168.1.101:637916379 myself,master - 0 0 1 connected 0-5460和从节点yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy 192.168.1.102:638016380 slave zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz 0 0 1 connected注意这里的16379就是前面的集群总线端口每个节点后面的端口号是它的总线端口不是业务端口。看到这些信息基本就能确认集群拓扑是符合预期的。4.3 数据读写验证搞懂CRC16槽位计算集群状态OK了接下来就是验证读写链路。Cluster模式下客户端连接任意节点如果key对应的槽位不在当前节点上节点会返回MOVED重定向错误客户端库会自行处理跳转。我们先手动验证一下这个机制能正常工作。先在一个主节点上写入数据127.0.0.1:6379 set user:1001 zhangsan OK 127.0.0.1:6379 get user:1001 zhangsan接着在另一个主节点上读取同一个key看看会发生什么127.0.0.1:102:6379 get user:1001 (error) MOVED 10439 192.168.1.101:6379返回的MOVED信息表示keyuser:1001对应的槽位是10439这个槽位在192.168.1.101:6379节点上。这说明集群的数据路由逻辑正常工作。正常情况下我们用的客户端SDK比如Java的Jedis、LettucePython的redis-py都会自动处理MOVED指令对应用层是透明的但如果用的是redis-cli需要加-c参数开启集群模式否则会直接报MOVED错误/usr/local/redis/bin/redis-cli -c -p 6379 -a MyRedisCluster2024-c参数让redis-cli自动跟随节点的重定向指示这样跨节点读写就不用手动指定了。关于槽位计算可以顺手做个验证。Redis Cluster用CRC16算法对key取CRC16值然后对16384取模得到槽位号。比如上面的user:1001落到槽位10439就是这个计算的结果。这个计算过程不用自己实现客户端库都帮你做了但理解这个概念有助于排查为什么某些key会落在某个节点上。4.4 故障转移验证手动关一个主节点集群的高可用能力不能停留在“理论上有”这个层面必须实操验证。我的验证方法是直接模拟主节点宕机观察集群是否能在阈值时间内自动完成故障转移。选定192.168.1.101:6379这个主节点把它直接停掉/usr/local/redis/bin/redis-cli -p 6379 -a MyRedisCluster2024 shutdown nosave然后观察集群日志和节点状态。正常情况下经过cluster-node-timeout我设置的15秒后集群会把这个主节点标记为fail并触发故障转移——它对应的从节点我这里是192.168.1.102:6380会被提升为新的主节点。用cluster nodes查看集群状态127.0.0.1:102:6379 cluster nodes会看到原本的从节点角色变成了master而且接管了原主节点负责的槽位。这说明自动故障转移成功。整个过程大概20秒左右符合预期。验证完毕后再把原来的主节点恢复启动。这里有个细节需要注意它启动后不会立刻恢复成主节点而是作为新的从节点挂到当前的主节点下面重新开始数据复制。这个行为是集群自动处理的对上层应用完全透明。如果你在生产环境做类似的故障演练建议在业务低峰期进行并且提前通知相关团队。虽然故障转移对客户端基本无感知但节点重启的瞬间连接池建连会有短暂的耗时波动。4.5 在线扩缩容水平扩展不是说说而已集群搭建好验证了基本功能和高可用性还不够还要验证集群的扩展能力。Redis Cluster支持在线增加节点和删除节点整个过程不需要停机。新增一个节点时我习惯用一个独立的端口比如在服务器A上再起一个6381端口实例配置文件和前面一样只是端口和目录不同。启动后先把它加入到集群/usr/local/redis/bin/redis-cli --cluster add-node \ 192.168.1.101:6381 \ 192.168.1.101:6379 \ -a MyRedisCluster2024这个命令会以6379作为“介绍人”把6381节点加入集群。加入后新节点默认是不负责槽位的需要手动执行reshard来分配槽位/usr/local/redis/bin/redis-cli --cluster reshard \ 192.168.1.101:6379 \ --cluster-from all \ --cluster-to 新节点ID \ --cluster-slots 4096 \ -a MyRedisCluster2024因为集群总共16384个槽位原来3个主节点平均分配新增一个主节点后理想情况是每个节点4096个槽位。所以这里把4096个槽位从所有老节点迁移到新节点。执行过程中会有交互式确认跟着提示走就行。迁移完成后再用cluster nodes查看确认新节点已经接管了部分槽位且原有节点各自的槽位数减少了。这就是水平扩容的完整过程。4.6 压测验证让数据说话最后一项验证是压测。Redis自带redis-benchmark工具可以方便地模拟并发读写。我用它跑了两个场景单节点基准压测和集群压测对比结果来确认集群模式下的性能损耗在可接受范围。单节点压测/usr/local/redis/bin/redis-benchmark -h 192.168.1.101 -p 6379 \ -a MyRedisCluster2024 -c 200 -n 1000000 -t set,get -d 100集群压测需要用集群模式/usr/local/redis/bin/redis-benchmark -h 192.168.1.101 -p 6379 \ -a MyRedisCluster2024 -c 200 -n 1000000 -t set,get -d 100 --cluster实测下来3主3从的集群在并发200、百万级操作请求下QPS轻松突破10万响应时间P99在个位数毫秒级别。和生产单节点相比因为数据分散到了多个节点性能不降反升。不过这里有个点要注意redis-benchmark的--cluster模式依赖一个与集群节点的交互能力如果你的安装在老版本上可能不支持该参数需要手动指定不同的节点来模拟请求分散效果。压测结束后记得查看机器的CPU、内存和网络负载确认集群的瓶颈在哪里。通常瓶颈会出现在网卡或者CPU单核上因为Redis是单线程模型IO多线程默认没开启的话多核利用不充分。如果CPU还没跑满但网卡先满了就该考虑扩容机器或者增加网卡带宽了。5. 常见问题与排查技巧实录5.1 集群状态卡在fail先查槽位分配和节点握手cluster_state:fail是最常见的集群异常状态。原因通常有两类一是槽位没有完全覆盖上面提到刚创建集群时是正常的0/16384二是集群中存在不可达节点。排查思路是这样的先看cluster_nodes输出找到标记为disconnected的节点确认它的IP:端口是否还能ping通如果网络没问题再看集群总线端口端口10000是否被防火墙拦截。我之前排查过一个案例业务端口6379通了但总线端口16379没放行节点之间无法通信集群一直报fail。处理方式很简单放行总线端口后再使用cluster meet命令让节点重新握手等几秒后集群状态会自动恢复。5.2 主从同步失败八成是masterauth的锅用着用着发现某个从节点数据一直不同步查看复制状态127.0.0.1:6380 info replication如果master_link_status:down并且日志里反复出现MASTER aborted replication with an error: NOAUTH Authentication required那基本可以确认是masterauth没配置或者密码不对。上面配置时我强调过requirepass和masterauth必须同时设置就是防这个坑。处理方法是在从节点的配置文件里补上正确的masterauth重启从节点实例复制关系就会自动恢复。生产环境还有一个隐蔽场景业务方修改了集群密码结果只改了requirepass忘了同步改masterauth导致整个集群的复制链路全部断裂。这个坑我见人踩过所以集群密码变更的checklist里一定要包含这两项。5.3 key分布不均匀导致热点问题集群模式下所有key被平均分布到16384个槽位理论上数据是均衡的。但实际业务中某些key的访问频率可能远高于其他key造成单节点热点拖累整个集群吞吐量。比如一个秒杀场景下的热卖商品ID所有请求都打向同一个key对应的槽位和节点负载就特别高。解决办法是给这些热点key加随机后缀把请求分散到不同的key上比如product:1001拆成product:1001:0到product:1001:9十个key这样它们的槽位散落到不同节点压力自然分散。代价是应用层需要多维护一层映射关系读的时候要把所有后缀key都查一遍。这个方案虽然土但非常有效是处理key热点问题的常用手段。另外Redis Cluster还支持hash tag机制可以让某些key强制落在同一个槽位。它的用法是如果key中含有{}Redis只对花括号内部的内容计算CRC16。比如user:{1001}:profile和user:{1001}:orders这两个key会落在同一个槽位。这在需要批量操作多个key比如MGET时非常有用因为Cluster模式下跨槽位的多key操作是不被保证原子性的而同一个槽位内可以。5.4 内存淘汰策略没设好导致写失败如果你在配置里没有设置maxmemory和maxmemory-policyRedis默认情况下内存满了就直接拒绝写入报错OOM command not allowed when used memory maxmemory。集群模式下这个问题的危害更大因为单个节点满了该节点负责的槽位无法写入等于整个集群的部分写入功能降级。我在配置里已经给出了推荐maxmemory 4gballkeys-lru。前者是内存水位后者是淘汰策略表示内存满时优先淘汰最近最少使用的key。这里有一个取舍allkeys-lru会淘汰所有key包括一些可能还需要的数据如果需要更精细的控制可以改用volatile-lru只淘汰设置了过期时间的key。但前提是你的业务key绝大多数都设置了TTL不然会导致内存无法释放。我这边业务上大量key本来就有过期时间所以用volatile-lru会更合适但为了安全兜底最终选了allkeys-lru至少保证写入一直可用。5.5 大量TIME_WAIT连接导致端口耗尽压测时遇到一个有趣的问题一段时间后客户端连接Redis报错Cannot assign requested address。排查后发现是客户端机器的TIME_WAIT状态连接堆积太多导致端口被耗尽了。这是因为高并发下客户端每次连接Redis后快速断开大量的TCP连接进入TIME_WAIT状态要等2MSL通常60秒才能释放。压测期间QPS高这个堆积速度远超释放速度。解决办法有几个方向客户端使用连接池不要每次请求都新建连接。大部分语言SDK默认维护连接池确保池大小设置合理即可。调整客户端的TCP参数允许端口复用sysctl -w net.ipv4.tcp_tw_reuse1缩短TIME_WAIT等待时间sysctl -w net.ipv4.tcp_fin_timeout15这是压测场景下的常用手段。在正式环境重点是确保连接池配置正确而不是无脑调内核参数。5.6 常见问题速查表现象可能原因排查与处理集群状态为fail槽位未分配完整、节点不可达执行cluster nodes检查断连节点确认总线和业务端口都放通从节点数据不同步masterauth密码不匹配检查info replication确认master_link_status修正masterauth后重启写操作报MOVED错误客户端未启用集群模式客户端连接时开启集群模式redis-cli加-c内存满了无法写入maxmemory和淘汰策略未配置设置合理的maxmemory和maxmemory-policy连接数过多触发TIME_WAIT客户端未使用连接池优化连接池配置必要时调内核TCP参数故障转移不触发cluster-node-timeout设置过大根据业务容忍度适当调小该参数扩容后槽位不均衡reshard操作不完整重新执行reshard合理分配迁移槽位数6. 个人经验与扩展建议集群搭建完成并全部验证通过后我最大的体会是搭建本身并不难真正花时间的是理解集群机制、设计合理的拓扑以及把故障转移、扩缩容这些运维动作都演练到位。有几个点想单独再强调一下。第一集群上线前一定要把监控做起来。我这边用Prometheus redis_exporter采集每个集群节点的指标包括内存使用率、命中率、主从复制延迟、槽位分布情况等。一旦某个节点的内存增长曲线异常或者复制延迟持续拉高监控告警会先于用户反馈发现问题。集群不是搭完就万事大吉后续的日常巡检才是保障稳定性的关键。第二备份策略不能因为集群就放松。有些朋友觉得“集群里每个主节点都有从节点数据肯定安全”这种想法很危险。从节点同步的数据是实时的但如果发生逻辑错误比如误执行了FLUSHALL、业务代码批量删除错误操作会立刻被复制到所有从节点集群的冗余保护是防不住这种人为事故的。所以集群模式下依然要定期做RDB备份而且备份要存放在独立的存储上不能和Redis节点在同一台机器。第三升级和运维操作要有预案。比如Redis大版本升级我一般会先在测试集群上完整跑一遍验证流程确认兼容性后再动生产。扩缩容操作尽量在业务低峰期执行并且提前确认客户端SDK支持集群模式避免因为客户端不支持MOVED重定向导致线上故障。后续如果你们的Redis集群规模再往上走还可以考虑引入官方提供的Redis Cluster Managerredis-cli --cluster之外的工具链比如一些图形化管理面板能直观看到每个节点的槽位和主从关系。但所有自动化和工具都建立在基础原理之上把这台集群彻底搞透后面再怎么变都不慌。