1. Redis Cluster手动搭建的痛点在哪里我最早接触Redis Cluster的时候是照着官方文档一步步敲命令。启动6个redis-server实例倒还好麻烦的是后面那一串集群初始化操作redis-cli --cluster create然后输入yes确认槽位分配方案再逐个检查主从对应关系。更难受的是如果中间某个节点启动失败或者端口被占用前面敲的一半命令就算白费了还得清理残留的appendonly、nodes.conf文件重新来过。有一次我在内网搭一个三主三从的测试集群6000到6005六个端口配置文件写一份改一份。当时想着图省事直接复制了第一份redis.conf然后全局替换端口号。结果启动之后slave节点全部连不上主节点排查了大半天发现是replicaof配置里写死了IP和端口某些实例的文件没改干净。这种问题本身不难但非常消磨耐心而且一遍遍重复操作毫无技术含量。后来我写了一个shell脚本把整个流程固化成一条命令检查环境、清理旧数据、生成配置、启动实例、等待端口就绪、自动创建集群、输出集群状态信息。实测下来从原来手忙脚乱的十几分钟压缩到十几秒还不会出错。这篇文章就围绕这个脚本展开讲讲我是怎么设计的关键步骤为什么这么写以及在真实环境里踩过的坑。如果你正在做Redis集群相关的测试、本地开发环境准备或者需要在多台服务器上快速拉起一套Cluster集群这篇文章可以直接照抄脚本改一改用。我不光贴完整代码还会把每一步背后的原理讲清楚。2. 写脚本之前先把这几个集群机制搞清楚脚本写得好不好取决于你对Redis Cluster的理解深不深。很多人上来就复制别人的脚本遇到问题完全不知道从哪里排查。所以先把几个关键机制过一遍。2.1 为什么一定要6个节点起步Redis Cluster要求每个主节点至少挂一个从节点这样主节点故障时从节点可以顶上来集群才具备高可用能力。所以最少需要3个主节点加上3个从节点也就是三主三从的结构。三个主节点分别负责一部分槽位从节点只做数据备份和故障转移不提供写服务但可以配置成可读。之所以要求最少3个主节点是因为集群脑裂时需要quorum投票2个主节点没法形成多数派投票1个节点就更不用说了。实际生产环境通常是5个主节点起步每个主节点带一个从节点甚至更多但测试环境三主三从就够了脚本也按这个规模来。2.2 槽位分配逻辑16384个数据桶整个Cluster集群只有16384个槽位slot均匀分给所有主节点。比如三个主节点每个节点负责大约5461个槽位。客户端要读写某个key时会先计算key的CRC16值然后对16384取模得到槽位编号再根据槽位所属的节点把请求路由过去。这就是为什么创建集群时redis-cli会打印出一个详细的槽位分配方案让你确认是否接受。比如Master[0] - Slots 0 - 5460 Master[1] - Slots 5461 - 10922 Master[2] - Slots 10923 - 16383脚本用redis-cli --cluster create的自动分配模式就不用手动指定每个节点的槽位范围了。redis-cli会根据节点数量自动计算全程只需要处理一次yes确认。2.3 集群总线端口多出来的10000每个Redis节点除了服务客户端请求的端口还会额外占用一个集群总线端口用于节点之间的心跳、握手、故障检测和槽位迁移等内部通信。总线端口是服务端口加10000比如服务端口是7000总线端口就是17000。这个机制对脚本设计很关键因为你在防火墙或安全组里如果只放开了服务端口忘记放开总线端口节点间根本无法建立集群连接。手动敲命令的时候node之间一直显示fail状态又不知道原因多半就是总线端口被挡了。脚本里最好加上端口连通性检查或者至少要在日志里明确提示。2.4 cluster meet 之后发生了什么手动创建集群的操作流程是启动所有实例然后用cluster meet命令让各个节点互相认识再分配槽位给每个主节点最后用cluster replicate命令为每个主节点指定从节点。这些操作本质上都是通过向节点发送命令完成的。redis-cli --cluster create帮我们把这些步骤封装起来了它内部会依次执行cluster meet、分配槽位、设置主从关系。脚本里直接调用这个子命令就能完成全部初始化大大降低出错率。不过要明确一点redis-cli --cluster create要求所有节点必须已经启动而且节点之间已经可以通过集群总线通信。所以脚本前面要先启动实例中间加一个等待端口就绪的步骤后面才执行创建命令顺序不能乱。3. 脚本设计思路让我少踩坑的三个核心决策在写脚本之前我参考了网上不少开源脚本也踩过一些别人踩过的坑所以做了一些关键设计决策。3.1 决策一用函数封装状态检查逻辑脚本的核心操作是启动Redis实例和创建集群但启动完之后不能马上执行创建命令。Redis进程启动需要一点时间尤其是第一次启动要生成RDB文件、初始化目录结构。如果启动后立刻执行cluster create大概率会报“Node XXX is not configured as a cluster node”之类的错误其实只是还没ready。我的方案是用一个wait_for_port函数循环检查特定端口是否已经能够建立TCP连接。端口通了才继续下一步最多重试30次每次间隔1秒。这样虽然脚本稍微长了一点点但稳定性和手动操作完全不是一个量级。3.2 决策二配置文件用heredoc动态生成而不是复制模板我在文章开头提到过踩坑复制模板再替换端口这事隐藏了很多问题。比如bind配置、dir配置、replicaof配置一旦漏改某个字段节点行为就完全不对了。所以脚本里用heredoc的方式每启动一个实例就现场生成一份对应端口的redis.config文件。所有节点共用一套配置模板只是端口、目录、cluster-config-file不同。这样做的另外一个好处是可读性更好。脚本本身就是配置的文档后面要加参数直接改heredoc块的内容就行。3.3 决策三支持带参数运行但也要提供默认参数一开始我写的脚本把所有变量都写死在文件顶部IP地址改成固定值。后来发现拿到别的机器上跑改来改去反而容易漏。于是改成支持命令行传参参数空缺时用默认值补偿。比如可以这样运行./create-redis-cluster.sh 192.168.1.10 7000 7001 7002 7003 7004 7005也可以直接不带参数运行默认使用本机IP和7000到7005端口。这样在单机测试和多机部署两个场景下都够用。4. 完整脚本从零一键拉起三主三从集群下面是完整的bash脚本。我已经在本地CentOS 7和macOS环境下都跑过配合Redis 6.x和7.x都能正常工作。#!/bin/bash # # create-redis-cluster.sh # 一键创建Redis Cluster集群三主三从 # 用法: # ./create-redis-cluster.sh [IP] [PORT1] [PORT2] ... # 示例: # ./create-redis-cluster.sh 192.168.1.100 7000 7001 7002 7003 7004 7005 # set -e # 默认参数 DEFAULT_IP$(hostname -I | awk {print $1}) DEFAULT_PORTS(7000 7001 7002 7003 7004 7005) # 读取参数 IP${1:-$DEFAULT_IP} PORTS(${:2}) if [ ${#PORTS[]} -eq 0 ]; then PORTS(${DEFAULT_PORTS[]}) fi if [ ${#PORTS[]} -lt 6 ]; then echo [ERROR] 至少需要6个端口来构建三主三从集群 exit 1 fi # 检查redis-server和redis-cli是否存在 which redis-server /dev/null 21 || { echo [ERROR] 未找到redis-server二进制请先安装Redis; exit 1; } which redis-cli /dev/null 21 || { echo [ERROR] 未找到redis-cli二进制请先安装Redis; exit 1; } BASE_DIR/opt/redis-cluster REDIS_CONFIG_TEMPLATEredis.conf log() { echo [$(date %Y-%m-%d %H:%M:%S)] $1 } cleanup() { log 开始清理旧配置和残留数据 rm -rf ${BASE_DIR} } wait_for_port() { local host$1 local port$2 local retries30 local count0 log 等待 ${host}:${port} 就绪 while ! nc -z $host $port 2/dev/null; do sleep 1 count$((count1)) if [ $count -ge $retries ]; then echo [ERROR] ${host}:${port} 等待超时 exit 1 fi done log ${host}:${port} 已就绪 } generate_config() { local port$1 local dir${BASE_DIR}/${port} local config_file${dir}/${REDIS_CONFIG_TEMPLATE} mkdir -p $dir cat $config_file EOF port ${port} bind 0.0.0.0 protected-mode no daemonize yes pidfile ${dir}/redis.pid logfile ${dir}/redis.log dir ${dir} appendonly yes appendfilename appendonly.aof appendfsync everysec cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 15000 maxmemory 256mb maxmemory-policy allkeys-lru EOF echo $config_file } start_redis() { local port$1 local config_file$2 redis-server $config_file log 已启动 redis-server端口 ${port} } create_cluster() { log 开始创建集群 local first_port${PORTS[0]} local args for port in ${PORTS[]}; do args${args}${IP}:${port} done printf yes\n | redis-cli --cluster create ${args} --cluster-replicas 1 } show_cluster_info() { log 集群创建完成节点信息如下 redis-cli -h $IP -p ${PORTS[0]} cluster nodes | grep -E master | slave || redis-cli -h $IP -p ${PORTS[0]} cluster nodes } # ---------- 主流程 ---------- log log Redis Cluster 一键创建脚本 log IP: ${IP} log 端口: ${PORTS[*]} log cleanup FLAG0 for port in ${PORTS[]}; do log 生成 ${port} 节点配置文件 cfg$(generate_config $port) done for port in ${PORTS[]}; do start_redis $port ${BASE_DIR}/${port}/${REDIS_CONFIG_TEMPLATE} done for port in ${PORTS[]}; do wait_for_port $IP $port done create_cluster show_cluster_info log Redis Cluster 创建完毕。连接方式: redis-cli -c -h ${IP} -p ${PORTS[0]} log 任意节点的可用密码: 无(测试环境建议仅在内网使用)4.1 逐段解读cleanup和generate_config为什么这么写cleanup函数直接删除整个BASE_DIR目录。这是测试环境最省心的做法确保每次跑出来的集群都是完全干净的状态。不过生产环境千万不要直接这么干数据没了就真的没了。所以脚本头部也标注了这是面向测试环境。generate_config用heredoc生成每个节点的配置文件。这里我把maxmemory设置成了256mb实际使用中根据机器内存调整即可。bind 0.0.0.0意味着监听所有网卡主要是为了多机部署场景方便但也意味着如果有外网IP存在安全风险生产环境要做额外加固。4.2 逐段解读create_cluster的执行细节create_cluster函数是脚本的关键。它把所有节点的地址拼接成参数字符串然后通过printf yes\n管道自动确认创建操作。redis-cli --cluster create会自动完成节点握手、槽位分配、主从关系设置这三个步骤比手动敲命令稳得多。--cluster-replicas 1的含义是每个主节点配备1个从节点。如果传6个端口最终会是3主3从如果传8个端口最终就是4主4从。脚本并没有限制只支持6端口其实传任意偶数端口都可以跑前提是端口数能被2整除。4.3 逐段解读为什么用hostname -I作为默认IPDEFAULT_IP$(hostname -I | awk {print $1})这个写法在单网卡机器上没问题但多网卡机器上取的是第一块网卡的IP可能不是你想绑定的那个。所以实际使用中更推荐显式传入IP参数或者改成手动配置。如果机器上没有安装nc命令wait_for_port函数里的nc -z会失败脚本会一直重试直到超时。所以依赖里应该加上ncnetcat用yum install nc或apt install netcat-openbsd装一下。或者你也可以用bash自带的/dev/tcp语法替代nc不过单位脚本里用nc更直观一些。5. 实测验证脚本跑通之后我这样确认集群真的没问题脚本输出只是第一步真正要确认集群是否健康还得看实际的状态和读写表现。5.1 cluster info和cluster nodes的状态解读跑完脚本后我用redis-cli -h 127.0.0.1 -p 7000 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:3state为ok说明槽位分配完整没有fail状态节点。cluster_known_nodes是6恰好对应用6个实例。如果这个数字小于6说明有的节点没有完成握手多半是总线端口通信问题。再看cluster nodes的输出xxx 192.168.1.100:700017000 master - 0 1695090000000 1 connected 0-5460 xxx 192.168.1.100:700117001 master - 0 1695090000000 2 connected 5461-10922 xxx 192.168.1.100:700217002 master - 0 1695090000000 3 connected 10923-16383 xxx 192.168.1.100:700317003 slave xxx 0 1695090000000 4 connected每行里的17000就是集群总线地址。看到master节点后面有connected和完整的槽位范围slave节点后面跟着主节点的ID这就说明集群的核心结构已经成型了。5.2 用redis-cli -c验证槽位跳转逻辑不带-c参数时redis-cli不感知集群信息如果访问的key不在当前节点的槽位范围会直接返回MOVED错误。带-c参数时客户端会自动跟随槽位跳转。实测一下redis-cli -c -h 127.0.0.1 -p 7000 set username zhangsan redis-cli -c -h 127.0.0.1 -p 7000 get username如果集群正常set和get都会返回OK和对应的值。你可以再用debug对象的方式确认key最终落在哪个节点上比如redis-cli -h 127.0.0.1 -p 7000 cluster keyslot username用这个命令能算出username这个key对应的槽位编号然后对照cluster nodes里的槽位分布就知道打到哪个主节点上了。5.3 故障转移实测把主节点杀了看看从节点能不能顶上来既然集群搭好了我建议顺手做个故障转移测试。找到7000端口对应的主节点PID直接kill掉然后观察集群反应kill -9 $(cat /opt/redis-cluster/7000/redis.pid) sleep 15 redis-cli -h 127.0.0.1 -p 7001 cluster nodes10到15秒之后(cluster-node-timeout默认15000ms)对应的从节点会升级成主节点顶上原主节点负责的槽位范围。虽然被杀的节点还没重启但整个集群的读写已经不受影响了。确认测试完成之后再重启7000让它作为新主节点的从节点重新加入集群。注意cluster-node-timeout设的是15000毫秒但故障转移时间还受从节点选举、数据同步等因素影响实际等待时间可能要更久一点。如果想知道具体进度可以在集群断掉期间看日志或者cluster info里的cluster_state变化。6. 生产环境落地脚本能用但至少得改这四个地方脚本本身是给开发测试用的如果直接照搬到生产环境大概率要出事。我自己经历过一次测试集群被扫到然后数据被清空的教训这里把关键点列出来。6.1 设置密码并启用ACL账号体系生产环境的Redis集群必须设置密码访问而且从Redis 6开始支持ACL可以为不同应用分配不同权限账号。配置文件里需要加入requirepass YourStrongPassword masterauth YourStrongPassword注意masterauth是主从复制时需要使用的密码。不设置这个从节点连主节点做同步时会被拒绝。集群环境中每个节点都要设置而且密码要一致。6.2 关闭危险命令和绑定内网地址生产环境建议在配置里加上rename-command把高危命令重命名掉比如rename-command FLUSHALL rename-command FLUSHDB rename-command CONFIG rename-command SHUTDOWN 同时bind的地址不要用0.0.0.0而是实际内网网段地址。多机部署时每个节点的bind配置最好精确到具体的网卡IP然后配合防火墙把服务端口和总线端口都限制在可信网段内。6.3 内存策略和持久化配置按业务调整脚本里的maxmemory 256mb适合测试生产环境应该根据业务预估和应用内存配额来设置。如果节点内存不足淘汰策略用allkeys-lru不一定合适有的业务需要volatile-lru或者noeviction。还有就是appendfsync everysec的配置在追求极致性能的场景可以考虑everysec甚至no但数据安全等级要求高的场景就要用always。6.4 从测试脚本到部署脚本的改造路线我个人的实践是把脚本中的清理逻辑去掉改成先检查端口占用再启动和加入集群。新节点加入的逻辑其实更简单带上cluster-enabled和cluster-announce-ip等参数启动然后执行redis-cli --cluster add-node把新节点加入已有集群即可。如果你面对的是一批新机器没有事先装好Redis脚本开头还要加入自动下载编译或通过包管理器安装Redis的步骤。到这一步脚本就从一个“测试工具”变成了一个“半自动化部署工具”。再往上走就是配置管理工具托管Redis集群安装那已经是另一个话题了。7. 最后再分享一个小技巧脚本搭完集群之后我习惯把每个节点的redis.pid和nodes.conf都保留下来。很多故障排查都需要看nodes.conf里的epoch和节点ID这个文件就是集群状态的权威记录。比如你想知道某个槽位到底归谁管看nodes.conf比跑命令更直接。另外如果哪天你需要清理整个集群重新来一遍手动清理最烦的是残留的nodes.conf和appendonly.aof。这两个文件只要存在节点重启时会试图恢复之前的集群状态导致你新生成的配置不生效。脚本里的cleanup函数直接删目录测试环境这里是对的。手动环境下至少要把nodes.conf删掉再重启否则集群永远“记得”旧世界。写脚本这事本质上就是把自己的操作经验和踩坑记录固化下来。我这份脚本对你最大的价值不是直接拿来用而是提供一个思路把重复劳动变成参数化、可复用的工具过程中遇到的每个坑都值得用注释和约定记录下来。以后你再搭Redis Cluster就不用再面对一屏幕的手动命令了。