企业官网建设流程全解析

简介：这份资源面向需要在 CentOS 7.X 环境下快速搭建 Redis 集群的运维与后端开发人员，提供一套可复用的自动化部署方案。它把主从复制、16384 个槽位分配、分布式哈希与故障转移等集群机制落地为可执行脚本，省去逐台手工配置的繁琐过程。压缩包共 5 个文件，以 3 个 sh 脚本为主，分别承担主流程调度、Redis 安装配置与集群卸载清理，另含 1 个 gz 源码包和 1 个 txt 说明文档，整体约 1.86MB，体积轻便、结构清晰。使用者只需按说明文档修改 IP 与端口，依次执行脚本，即可完成从源码编译安装到集群组建的全流程，同时可借助卸载脚本快速回滚环境。目前已有 775 人学习下载，适合希望降低集群部署门槛、理解自动化运维思路的中级读者参考。

1. CentOS 上跑 Redis 集群：为什么我劝你别手动一台台装

三台 CentOS 7.9 的机器摆在面前，每台都要装 Redis、改配置、开端口、建集群，手动敲一遍至少四十分钟，敲完还得祈祷没打错 IP。更玄学的是，Redis 集群对节点握手顺序、槽位分配、配置文件里的cluster-config-file路径都挺敏感，一个参数写歪，redis-cli --cluster create就卡在Waiting for the cluster to join不动了。我见过太多人第一次搭 Redis 集群，卡在“节点互相看不见”这一步，翻日志翻到怀疑人生。这份redis集群一键自动部署脚本.rar就是冲着这个场景来的——它把三主三从的安装、配置、启动、建集群全流程压进一个 shell 脚本里，适合需要在 CentOS 上快速拉起一套可用 Redis 集群、又不想被手工步骤反复折磨的开发者。下面我从环境准备开始，把这份脚本怎么用、参数怎么改、坏了怎么救，一步步拆开。

2. 环境先列清：CentOS 版本、Redis 版本和依赖包

2.1 系统与版本对照表

这份脚本面向的是 CentOS 7 系列，我在 7.6 和 7.9 上都跑过，表现一致。CentOS 8 理论上也能用，但yum源和firewalld默认策略有差异，需要额外确认。Redis 版本方面，脚本默认拉取的是 5.0.x 稳定分支，这是目前生产环境里兼容性最好的一档——6.x 之后的多线程 IO 和 ACL 虽然香，但集群模式下部分客户端库还没完全跟上，新手贸然上 6.x 容易在连接层翻车。

注意：如果你的机器是 CentOS 8 或 Rocky Linux，yum install那一步可能报No package gcc available，需要先换源或启用powertools仓库，这不是脚本的问题，是系统源配置的事。

2.2 安装前必须确认的三件事

第一，确认三台机器之间网络互通，且时间同步。Redis 集群靠 gossip 协议通信，节点间时间差超过阈值会导致cluster-node-timeout误判，把正常节点踢出集群。我一般先跑一遍ntpdate或chronyd同步，再继续。

# 在三台机器上分别执行，确认时间偏差在 1 秒内 date # 如果偏差大，用 chronyd 同步 sudo yum install -y chrony sudo systemctl enable --now chronyd chronyc sources -v

第二，确认firewalld状态。脚本会尝试自动开放 Redis 端口（默认 7000-7005 和集群总线端口 17000-17005），但如果firewalld没启动，脚本会跳过这步，你需要自己确认iptables规则。

# 查看 firewalld 是否运行 systemctl status firewalld # 如果运行中，确认端口已放行 firewall-cmd --list-ports

第三，确认selinux不会拦路。CentOS 默认开启 SELinux，Redis 写cluster-config-file时可能被拒绝。我一般临时设为 permissive 模式，装完再按需调整。

# 查看当前 SELinux 状态 getenforce # 临时设为 permissive（重启后失效） sudo setenforce 0

这三步做完，环境基本就干净了。脚本本身不负责改 SELinux 和防火墙，它假设你已经把基础环境理顺——这是运维脚本的常见做法，把系统层的事留给系统层解决。

2.3 脚本目录结构预览

解压redis集群一键自动部署脚本.rar后，你会看到一个主脚本和几个辅助文件。主脚本通常叫redis_cluster_install.sh，辅助文件包括redis.conf.template（配置模板）和nodes.conf（集群节点信息，首次运行后生成）。脚本的设计思路是：你只需要改脚本开头几个变量，剩下的它自己跑。

# 解压后进入目录 tar -xvf redis集群一键自动部署脚本.rar cd redis_cluster_install # 查看文件列表 ls -l # 给主脚本加执行权限 chmod +x redis_cluster_install.sh

这里有个细节：.rar格式在 CentOS 上默认不支持，需要先装unrar。如果你拿到的是.tar.gz或.zip，对应命令换成tar -zxvf或unzip即可。我一般会在跳板机上先解压好，再把目录同步到三台目标机器，避免每台都装解压工具。

3. 脚本核心参数：改哪几个变量就能跑

3.1 节点 IP 和端口分配

脚本开头通常有一段变量定义区，这是你唯一需要动的地方。以三主三从为例，你需要填六个 IP 和端口组合。常见做法是把三台机器各跑两个实例，主从交叉分布，避免一台挂了带走一主一从。

# 编辑脚本，找到变量定义区 vim redis_cluster_install.sh # 以下为需要修改的核心变量示例 NODE_IPS=("192.168.1.101" "192.168.1.102" "192.168.1.103") NODE_PORTS=(7000 7001 7002 7003 7004 7005) MASTER_COUNT=3 REPLICA_COUNT=1 REDIS_PASSWORD="YourStrongPass123"

NODE_IPS是三台机器的内网 IP，NODE_PORTS是六个实例的端口。脚本会按顺序把前三个端口分配给主节点，后三个分配给从节点，并自动做replicaof绑定。REDIS_PASSWORD如果留空，集群就不设密码；生产环境我强烈建议设上，否则任何能连到端口的人都能操作你的数据。

提示：端口不要用 6379 默认值，集群模式下多实例同机部署时，端口冲突是最常见的翻车点。7000 起步是社区惯例，避开常用服务端口。

3.2 数据目录与日志路径

脚本默认把数据放在/data/redis/{port}下，日志放在/var/log/redis/{port}.log。如果你的数据盘挂载点不是/data，需要改DATA_DIR变量。我一般会把数据目录单独挂一块盘，避免 Redis 的 AOF 和 RDB 文件把系统盘写满。

# 数据目录和日志目录配置 DATA_DIR="/data/redis" LOG_DIR="/var/log/redis" # 脚本会自动创建子目录，但父目录需要提前存在 sudo mkdir -p /data/redis /var/log/redis sudo chown -R $(whoami):$(whoami) /data/redis /var/log/redis

DATA_DIR下的每个端口子目录会包含dump.rdb、appendonly.aof和nodes.conf。其中nodes.conf是集群状态文件，删了它等于把节点从集群里“失忆”，需要重新cluster meet。我见过有人清理磁盘时顺手删了nodes.conf，结果整个集群槽位错乱，血泪经验。

3.3 集群超时与副本参数

脚本生成的redis.conf模板里，有几个集群相关参数值得单独说。cluster-node-timeout默认 15000 毫秒，意思是节点失联超过 15 秒才标记为疑似下线。如果你的网络抖动大，可以调到 30000；如果追求快速故障转移，可以降到 5000，但误判概率会上升。

# 脚本模板中的关键集群参数 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 15000 cluster-require-full-coverage no appendonly yes appendfsync everysec

cluster-require-full-coverage no这个参数很关键。默认是yes，意味着只要有一个槽位不可用，整个集群就拒绝写入。设为no后，部分槽位失联时其他槽位仍可读写，可用性更高。生产环境我一般设no，但你要清楚这意味着可能读到旧数据。

4. 执行安装：从解压到集群握手的完整命令流

4.1 单机预检与依赖安装

脚本执行前，建议先跑一遍预检。我一般会手动确认gcc、make、wget这三个命令存在，因为脚本编译 Redis 源码时依赖它们。如果缺失，脚本会报错退出，但报错信息可能不够直观。

# 预检依赖 which gcc make wget # 如果有缺失，先装上 sudo yum install -y gcc make wget # 确认版本 gcc --version | head -1

这一步在每台机器上都要做。脚本本身不会自动装依赖，这是有意为之——运维脚本不应该擅自改系统包，否则在受控环境里可能触发合规问题。我习惯把预检命令写成一个precheck.sh，三台机器并行跑一遍，确认全绿再执行主脚本。

4.2 主脚本执行与输出解读

确认环境干净后，在主节点（通常是第一台机器）上执行脚本。脚本会依次做：下载 Redis 源码、编译、生成六个实例的配置文件、启动六个实例、执行redis-cli --cluster create建集群。

# 在主节点执行，传入所有节点 IP 和端口 ./redis_cluster_install.sh \ --nodes "192.168.1.101:7000,192.168.1.102:7001,192.168.1.103:7002,192.168.1.101:7003,192.168.1.102:7004,192.168.1.103:7005" \ --password "YourStrongPass123" \ --replicas 1

执行过程中，你会看到类似Waiting for the cluster to join的输出。这是正常现象，脚本在等所有节点完成握手。如果卡在这里超过 30 秒，通常是端口没通或密码不一致。脚本最后会输出[OK] All 16384 slots covered，看到这行才算成功。

注意：如果脚本中途失败，不要直接重跑。先检查/data/redis/{port}/nodes.conf是否残留，残留的集群状态会导致新集群建不起来。我一般会先清理所有节点的数据目录，再重新执行。

4.3 验证集群状态的三条命令

脚本跑完后，别急着庆祝。先连上去看一眼集群状态，确认槽位分配和主从关系符合预期。

# 连接任意节点，查看集群信息 redis-cli -c -h 192.168.1.101 -p 7000 -a YourStrongPass123 cluster info # 查看节点列表和主从关系 redis-cli -c -h 192.168.1.101 -p 7000 -a YourStrongPass123 cluster nodes # 查看槽位分配 redis-cli -c -h 192.168.1.101 -p 7000 -a YourStrongPass123 cluster slots

cluster info里cluster_state:ok表示集群健康，cluster_slots_assigned:16384表示槽位全覆盖。cluster nodes会列出六个节点，每个主节点后面跟着它的从节点 ID。如果看到某个节点状态是fail或handshake，说明握手没完成，需要排查网络和密码。

5. 避坑与排查：五个让我熬夜的集群故障

5.1 现象：建集群卡在 Waiting for the cluster to join

原因通常是节点间总线端口不通。Redis 集群除了服务端口（7000-7005），还需要总线端口（服务端口 + 10000，即 17000-17005）。很多人只开了服务端口，忘了总线端口，导致节点互相看不见。

解决：确认firewalld或iptables放行了 17000-17005。如果用的是云主机，安全组也要放行。我一般直接用telnet从一台机器连另一台的总线端口，通了再继续。

# 从 101 连 102 的总线端口 telnet 192.168.1.102 17001 # 如果连不上，检查防火墙 sudo firewall-cmd --add-port=17000-17005/tcp --permanent sudo firewall-cmd --reload

5.2 现象：集群状态 ok 但写入报 CLUSTERDOWN

原因通常是槽位没分配完，或者cluster-require-full-coverage设为yes且部分槽位失联。脚本建集群时如果中途被打断，可能只分配了部分槽位。

解决：用redis-cli --cluster fix修复，或者手动cluster addslots补上缺失槽位。我一般先cluster slots看缺哪些，再补。

# 检查槽位覆盖情况 redis-cli -c -h 192.168.1.101 -p 7000 -a YourStrongPass123 cluster slots | grep -c "16383" # 如果不足，用 fix 命令 redis-cli --cluster fix 192.168.1.101:7000 -a YourStrongPass123

5.3 现象：从节点一直显示 connecting

原因可能是主节点密码和从节点不一致，或者replicaof指向的 IP 端口写错。脚本生成的配置里，从节点的replicaof是自动填的，但如果 IP 填错，从节点会一直重连。

解决：登录从节点，info replication看master_link_status。如果是down，检查redis.conf里的replicaof行和masterauth行。

# 在从节点上查看复制状态 redis-cli -h 192.168.1.101 -p 7003 -a YourStrongPass123 info replication # 关注 master_link_status 和 master_host 字段

5.4 现象：重启机器后集群起不来

原因通常是nodes.conf和实际 IP 不匹配，或者 Redis 没设开机自启。脚本默认不配systemd，机器重启后实例不会自动拉起。

解决：手动写systemdunit 文件，或者用脚本自带的start_all.sh批量启动。我一般会配systemd，每个端口一个 service，Restart=always。

# 示例 systemd unit（以 7000 端口为例） sudo tee /etc/systemd/system/redis-7000.service <<EOF [Unit] Description=Redis Cluster Node 7000 After=network.target [Service] ExecStart=/usr/local/bin/redis-server /data/redis/7000/redis.conf Restart=always User=$(whoami) [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now redis-7000

5.5 现象：内存告警但数据量不大

原因可能是maxmemory没设，或者 AOF 重写缓冲区占用过高。Redis 集群模式下，每个节点独立管理内存，不设上限会一直吃到系统 OOM。

解决：在redis.conf里设maxmemory和maxmemory-policy。我一般设物理内存的 70%，策略用allkeys-lru。

# 在配置模板中追加 maxmemory 2gb maxmemory-policy allkeys-lru # 改完后滚动重启各节点

6. 装完怎么验证：三主三从的读写与故障转移测试

脚本跑完、cluster info显示ok，这只是第一步。真正要确认集群能用，得做两件事：跨节点读写和模拟故障转移。我一般会写一个小的验证脚本，把这两步串起来。

#!/bin/bash # verify_cluster.sh - 验证 Redis 集群读写和故障转移 PASS="YourStrongPass123" NODES=("192.168.1.101:7000" "192.168.1.102:7001" "192.168.1.103:7002") # 1. 跨节点写入 100 个 key for i in $(seq 1 100); do redis-cli -c -h 192.168.1.101 -p 7000 -a $PASS set "testkey:$i" "value$i" > /dev/null done echo "[OK] 写入 100 个 key 完成" # 2. 从另一个节点读取，验证数据同步 for i in $(seq 1 100); do VAL=$(redis-cli -c -h 192.168.1.102 -p 7001 -a $PASS get "testkey:$i") if [ "$VAL" != "value$i" ]; then echo "[FAIL] key testkey:$i 读取不一致" exit 1 fi done echo "[OK] 跨节点读取一致" # 3. 模拟主节点故障：kill 掉 7000 端口的 redis 进程 MASTER_PID=$(redis-cli -h 192.168.1.101 -p 7000 -a $PASS info server | grep process_id | cut -d: -f2 | tr -d '\r') kill -9 $MASTER_PID echo "[INFO] 已 kill 主节点 7000，等待故障转移..." # 4. 等待 20 秒，检查集群状态 sleep 20 redis-cli -c -h 192.168.1.102 -p 7001 -a $PASS cluster info | grep cluster_state # 如果输出 cluster_state:ok，说明从节点已提升为主

这个脚本的逻辑是：先跨节点写读，确认数据同步正常；然后 kill 掉一个主节点，等 20 秒看集群是否自动完成故障转移。如果cluster_state仍是ok，说明从节点成功顶替。这一步做完，你才算真正验证了集群的高可用。

提示：故障转移测试会触发主从切换，生产环境慎用。我一般只在 staging 环境跑，或者挑业务低峰期做。测试完记得把 kill 掉的节点重新拉起，它会以从节点身份重新加入。

从那以后我每次搭完 Redis 集群，都强制走一遍这个验证脚本，不看到cluster_state:ok和跨节点读写一致，绝不把集群交给业务方。希望帮到你。

本文还有配套的精品资源，点击获取