简介：这份资源面向需要在 CentOS 7.X 上快速搭建 Redis 集群的运维与后端开发人员，提供一套可复用的自动化部署方案，省去手工编译、逐台配置的繁琐流程。压缩包共 5 个文件，以 3 个 shell 脚本为主，辅以 1 个 Redis 5.0.0 源码压缩包和 1 份说明文档，整体约 1.86MB，体积轻巧便于分发。脚本覆盖安装、配置与卸载环节，可自动完成源码解压编译、节点参数写入、集群槽位分配与故障转移相关设置，并处理防火墙端口与 SELinux 策略等常见阻碍；说明文档则给出修改 IP、端口等关键变量的指引，读者只需按需调整即可在多台机器上批量执行。目前已有 775 人学习下载，适合希望理解主从复制、16384 槽分配与分布式哈希机制，并借助脚本快速落地集群环境的中高级使用者参考。
1. 从一台干净的 CentOS 说起：为什么我劝你别再手搓 Redis 集群
上周帮一个朋友救火，他负责的一套业务系统在凌晨两点挂了，原因说出来有点哭笑不得——半年前他手动搭的三主三从 Redis 集群，其中一台从节点所在的宿主机磁盘写满，触发主从切换后，新的主节点配置没同步上，整个集群进入 fail 状态，业务侧连接池全部超时。他翻出当时的部署笔记，发现连自己都记不清那几个redis.conf里到底改了哪些参数。这不是个例，我见过太多团队在 CentOS 上装 Redis 集群，第一次靠搜索引擎拼凑命令，第二次靠记忆，第三次就彻底失控。
Redis 集群本身不算复杂，但「在 CentOS 上从零把它装稳」这件事，坑远比想象中密集：系统自带的源版本太老、ruby 环境缺失导致redis-trib.rb跑不起来、防火墙和 SELinux 把集群总线端口拦掉、节点配置文件里cluster-config-file路径写错导致重启后集群信息丢失。这些问题单看都不难，凑在一起就变成玄学。这份redis集群一键自动部署脚本.rar想解决的，就是把上面这些重复劳动和记忆负担收进一个可复用的流程里，让一台干净的 CentOS 机器能在十几分钟内变成可用的集群节点。它适合两类人：一是第一次在 CentOS 上搭 Redis 集群、不想被环境问题劝退的新手；二是已经搭过但每次都要重新查参数、想把这套流程固化下来的运维。接下来我按实际落地顺序，把版本选择、脚本拆解、配置项取舍和验证方法一层层拆开讲。
2. 环境准备与版本选择：CentOS 7/8 下装什么、从哪拿
2.1 系统版本与依赖清单
CentOS 7 和 CentOS 8 在 Redis 集群部署上的差异，主要不在 Redis 本身，而在包管理器和默认软件版本。CentOS 7 默认的yum源里 Redis 是 3.2，CentOS 8 的dnf源里是 5.0，这两个版本都偏旧，而且 CentOS 8 已经停止维护，很多镜像源需要手动换。我一般不会用系统源装 Redis，而是直接编译安装，版本可控，路径清晰。
在动手之前，先把依赖装齐。下面这套命令在 CentOS 7 和 8 上都能跑，区别只是yum和dnf的写法，我统一用yum，CentOS 8 上yum是dnf的软链，不影响：
# 基础编译工具链，gcc 版本别太低，CentOS 7 默认 4.8.5 够用 yum install -y gcc gcc-c++ make # tcl 是 Redis 自带的测试套件依赖，不装 make test 会报错 yum install -y tcl # ruby 和 rubygems 是 redis-trib.rb 的前置，Redis 5 之后用 redis-cli --cluster 可以替代 yum install -y ruby rubygems # 如果打算用 redis-trib.rb，还需要装 redis gem gem install redis这里有个版本取舍：Redis 5.0 开始，官方把集群管理工具从redis-trib.rb迁移到了redis-cli --cluster，不再依赖 ruby。如果你选 Redis 5 或 6，上面 ruby 那两行可以省掉，少一个环境变量和 gem 源的问题。我现在的习惯是直接用 Redis 6.2.x，稳定、支持 ACL、集群命令成熟，而且redis-cli --cluster的报错信息比老版本清楚得多。
2.2 下载与目录规划
Redis 源码从官方站点拿，版本我选6.2.14，这是 6.2 分支后期的一个稳定版，修了不少集群相关的边界问题。下载和解压：
# 统一放在 /usr/local/src 下，方便后续清理 cd /usr/local/src 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 install默认装到/usr/local/bin，而是指定PREFIX，把二进制和配置文件分开管理：
# PREFIX 指定安装根目录，后续所有节点共用这一份二进制 make PREFIX=/usr/local/redis6 MALLOC=libc -j$(nproc) make PREFIX=/usr/local/redis6 installMALLOC=libc这个参数在 CentOS 上建议加上，默认的 jemalloc 在某些内核版本下会有内存碎片问题，libc 的 malloc 更稳。-j$(nproc)是按 CPU 核数并行编译，能快不少。装完之后/usr/local/redis6/bin下会有redis-server、redis-cli、redis-benchmark等可执行文件。
目录规划上，我习惯给每个节点单独一个目录，比如/data/redis/7001、/data/redis/7002，每个目录里放自己的redis.conf、日志、RDB/AOF 文件和集群配置文件。这样后面脚本生成配置时，路径替换逻辑简单，出问题也好定位是哪个节点。
提示：CentOS 8 的
wget如果提示证书问题，先yum install -y ca-certificates更新根证书，再重试。
3. 脚本拆解与手动部署：一键背后到底做了什么
3.1 脚本的目录结构与执行入口
拿到redis集群一键自动部署脚本.rar之后，先解压看结构。这类脚本通常包含一个主入口 shell、一个配置模板、一个节点生成逻辑，可能还有一份 README。解压命令：
# 安装 unrar，CentOS 默认没有 yum install -y unrar unrar x redis集群一键自动部署脚本.rar /opt/redis-cluster-script/ cd /opt/redis-cluster-script/ ls -l假设解压后看到deploy.sh、redis.conf.tpl、nodes.conf.tpl这几个文件。deploy.sh是入口，redis.conf.tpl是配置模板，脚本会读取模板里的占位符，替换成每个节点的端口、路径、集群总线端口，然后生成实际的redis.conf。这种模板替换的做法比在脚本里硬编码sed命令要清晰，改参数只需要动模板。
执行前先给脚本加执行权限，并且用bash -x跑一遍看它到底执行了哪些命令，这一步很重要，能提前发现路径写死、变量未定义之类的问题：
chmod +x deploy.sh # -x 打印每条执行的命令，-n 只做语法检查不执行 bash -n deploy.sh bash -x deploy.sh 2>&1 | head -50如果脚本里写死了/usr/local/redis这种路径，而你的二进制装在/usr/local/redis6，就需要改脚本里的REDIS_HOME变量。我一般会在脚本开头找REDIS_HOME=、NODE_COUNT=、BASE_PORT=这几个变量，确认它们和实际环境一致再往下走。
3.2 节点配置模板的关键参数
不管脚本怎么封装，最终落到每个节点上的redis.conf才是决定集群能不能起来的东西。下面这份是脚本模板里最核心的一段，我按参数逐个说明：
# 节点端口，集群模式下每个节点必须不同 port 7001 # 集群总线端口，默认是 port + 10000，节点间通信走这个端口 cluster-enabled yes # 集群配置文件，记录节点 ID、槽位分配、主从关系，必须可写 cluster-config-file nodes-7001.conf # 节点超时时间，单位毫秒，超过这个时间没响应就认为节点下线 cluster-node-timeout 15000 # 开启 AOF 持久化，集群模式下建议开，RDB 在故障恢复时可能丢更多数据 appendonly yes appendfilename "appendonly-7001.aof" # 绑定地址，集群节点间需要互通，不能只绑 127.0.0.1 bind 0.0.0.0 # 关闭保护模式，否则外部无法连接 protected-mode no # 后台运行 daemonize yes # 日志和数据的存放路径，每个节点独立 dir /data/redis/7001 logfile /data/redis/7001/redis.logcluster-node-timeout这个值我一般设 15000，默认的 15000 在虚拟机或跨机房场景下偏短，容易误判。如果节点部署在同一台机器上做测试，5000 也能跑，但生产环境别低于 10000。cluster-config-file的路径一定要和dir配合好，脚本生成时如果只写了文件名，Redis 会把它放在dir下，这没问题；但如果写了绝对路径而目录不存在，节点启动会直接失败。
appendonly yes在集群里不是必须，但一旦某个主节点挂了，从节点提升为主，AOF 能让数据恢复更完整。代价是磁盘 IO 和文件体积，测试环境可以关掉换性能。
3.3 手动跑一遍集群创建命令
脚本封装得再好，你也得知道它背后调的是什么。Redis 6 用redis-cli --cluster创建集群，假设六个节点分别在 7001 到 7006，三主三从：
# 先逐个启动节点 for port in 7001 7002 7003 7004 7005 7006; do /usr/local/redis6/bin/redis-server /data/redis/$port/redis.conf done # 创建集群，--cluster-replicas 1 表示每个主节点配一个从节点 /usr/local/redis6/bin/redis-cli --cluster create \ 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 \ 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 \ --cluster-replicas 1执行后会提示你确认槽位分配方案，输入yes回车。如果卡在Waiting for the cluster to join，八成是集群总线端口没通，检查防火墙有没有放行 17001 到 17006。脚本通常会自动处理这些，但手动跑一遍能让你在脚本出问题时知道卡在哪一步。
注意：
--cluster-replicas 1里的 1 是每个主节点的从节点数量，不是从节点总数。六个节点三主三从，这个值就是 1；如果九个节点三主六从，要写 2。
4. 避坑与排查：集群起不来时先看这五条
4.1 现象：节点启动后cluster_state:fail
原因通常是槽位没有完全分配，或者有节点没加入集群。用redis-cli -p 7001 cluster info看cluster_state，如果是fail，再看cluster slots有没有覆盖 0 到 16383。解决方法是重新执行--cluster create，或者在已有集群上用--cluster fix修复：
/usr/local/redis6/bin/redis-cli --cluster fix 127.0.0.1:7001fix会尝试重新分配槽位和修复主从关系，但前提是节点之间网络是通的。
4.2 现象：Waiting for the cluster to join一直不结束
这是最经典的坑。原因有两个：一是集群总线端口被防火墙拦了，二是bind配置只绑了 127.0.0.1，节点间用内网 IP 通信时连不上。解决：
# 放行集群总线端口，假设节点端口 7001-7006 firewall-cmd --permanent --add-port=17001-17006/tcp firewall-cmd --reload # 或者临时关掉防火墙排查（生产别这么干） systemctl stop firewalld同时确认redis.conf里bind 0.0.0.0或者绑了正确的内网 IP，protected-mode no。
4.3 现象：重启后集群信息丢失，节点变成独立实例
原因是cluster-config-file指向的nodes-*.conf被删了或者路径不可写。这个文件记录节点 ID 和集群状态，Redis 启动时会读它，读不到就当新节点处理。解决：检查dir目录权限，确保 Redis 运行用户有写权限；脚本生成配置时别把nodes.conf放在/tmp这种会被清理的目录。
4.4 现象：gem install redis报错Unable to require openssl
这是 CentOS 7 上 ruby 环境的老问题，openssl-devel没装或者 ruby 编译时没链接到 openssl。解决：
yum install -y openssl-devel # 如果还不行，换用 redis-cli --cluster，彻底绕开 ruby这也是我推荐 Redis 5 以上版本的原因，少一层依赖少一堆事。
4.5 现象：脚本执行到一半报Permission denied
原因通常是脚本里用了sudo但当前用户不在 sudoers 里，或者目标目录属主不对。解决：用 root 执行，或者提前chown -R redis:redis /data/redis。我一般会创建一个专用用户跑 Redis，不用 root，降低误操作风险。
5. 装完怎么验证：从集群状态到读写压测走一遍
集群创建完不算完，得验证它真的能扛住读写和故障切换。我习惯按下面这个顺序走一遍，每一步都有明确的预期结果。
第一步，看集群整体状态。在任意节点执行：
/usr/local/redis6/bin/redis-cli -p 7001 cluster info预期输出里cluster_state:ok、cluster_slots_assigned:16384、cluster_known_nodes:6、cluster_size:3。这四个值对不上，说明集群没建完整，回到第 4 章排查。
第二步，看槽位分配和主从关系：
/usr/local/redis6/bin/redis-cli -p 7001 cluster nodes输出里每个节点一行，master和slave角色清楚，从节点后面会跟着它对应的主节点 ID。确认三主三从，且每个主节点都有从节点挂载。
第三步，做一次跨槽读写。集群模式下，redis-cli要加-c参数才会自动重定向到正确节点：
# -c 开启集群模式，key 会被重定向到对应槽位的节点 /usr/local/redis6/bin/redis-cli -c -p 7001 set foo bar /usr/local/redis6/bin/redis-cli -c -p 7001 get foo如果set返回OK，get返回bar，说明读写链路通了。再试一个会落到不同槽位的 key，比如set hello world，观察它是否被重定向到另一个节点。
第四步，模拟故障切换。找到 7001 对应的从节点端口，假设是 7004，先kill掉 7001 的进程，然后等cluster-node-timeout时间（15 秒）过去，再看cluster nodes：
# 杀掉主节点进程 kill $(cat /data/redis/7001/redis.pid) # 等待 15 秒以上，观察从节点是否提升为主 sleep 20 /usr/local/redis6/bin/redis-cli -p 7002 cluster nodes预期是 7004 从slave变成master，并且接管了 7001 原来的槽位。如果没切换，检查cluster-node-timeout是不是设太长，或者从节点和主节点之间的网络是不是有问题。
第五步，用redis-benchmark做一轮压测，确认集群在负载下不崩：
# -c 并发连接数，-n 总请求数，--cluster 让 benchmark 走集群模式 /usr/local/redis6/bin/redis-benchmark -h 127.0.0.1 -p 7001 -c 50 -n 10000 --cluster看requests per second和latency两个指标，只要没有大量 error，延迟在可接受范围，这套集群就算跑通了。
最后说个我自己的习惯：每次装完集群，我会把cluster nodes的输出和redis.conf里改过的参数一起存一份到/data/redis/cluster-snapshot-$(date +%F).txt。半年前那次救火，如果朋友当时留了这份快照，恢复时至少能省两个小时。从那以后我每次部署完都强制走一遍这个快照留存，不管多熟的流程。希望这套脚本和上面的验证步骤，能帮你把 Redis 集群在 CentOS 上真正跑稳。
本文还有配套的精品资源，点击获取
