企业官网建设流程全解析

简介：这份资源面向需要在 CentOS 7.X 环境下快速搭建 Redis 集群的运维与后端开发人员，提供一套可复用的自动化部署方案。包内共 5 个文件，以 3 个 shell 脚本为主，辅以 1 个 Redis 5.0.0 源码压缩包和 1 份说明文档，整体约 1.86MB。脚本覆盖从源码解压、编译安装到集群配置、卸载清理的完整流程，使用者只需按说明修改 IP 与端口等变量，即可在多台机器上批量执行，省去逐台手工配置的繁琐。资源同时涉及主从复制、16384 个槽位分配、分布式哈希与故障转移等集群核心机制，并兼顾 yum 依赖安装、firewalld 端口放行及 SELinux 策略等 CentOS 常见配置要点，便于理解脚本背后的原理。目前已有 775 人学习下载，适合希望降低集群搭建门槛、快速验证部署流程的读者参考使用。

1. 从一台裸 CentOS 到三主三从：这个 Redis 集群脚本到底省掉了哪几步

手上拿到一台刚装好的 CentOS，要把它变成能扛住主节点宕机的 Redis 集群，正常流程是编译安装、改六份配置、逐个拉起实例、再用redis-cli --cluster create拼集群、最后手动分配槽位。这套动作做一遍半小时，做十遍就是五小时，而且每次卡在哪一步都得重新翻笔记。这份redis集群一键自动部署脚本.rar解决的就是这个重复劳动——它把「装 Redis、起多实例、组集群、验状态」压成一条命令，适合需要频繁重建测试环境的后端和运维，也适合第一次搭集群、想对照脚本理解每一步在干什么的人。下面我按自己拆包复现的顺序，把脚本里真正干活的部分和几个容易翻车的点讲清楚。

2. 拆开压缩包先看结构：脚本把哪些步骤固化成了配置

2.1 目录布局与文件职责

解压之后不要急着执行，先tree或者ls -R看一遍。这类一键脚本的典型结构是：一个主入口 shell、一个配置模板目录、一个安装包或在线下载逻辑、一个集群创建脚本。我拿到的这份大致是这样：

# 查看解压后的目录结构 tar -xf redis集群一键自动部署脚本.rar -C ./redis-deploy cd redis-deploy find . -maxdepth 2 -type f | sort

执行后一般能看到install.sh（主入口）、conf/（redis-7000.conf到redis-7005.conf这类模板）、redis-cli.sh（集群创建与校验）、可能还有一个redis-x.x.x.tar.gz离线包。逻辑说明：主入口负责环境检查和安装，conf/里每个文件对应一个实例，端口从 7000 递增；集群创建脚本读取这些端口拼出--cluster create的参数。参数说明：-maxdepth 2只列两层，避免把源码目录里几千个文件刷屏；-type f过滤掉目录，只看文件。

这里有个判断脚本质量的小技巧：如果conf/里的配置文件是写死的绝对路径，换台机器就得改；好的脚本会用变量拼路径。我一般先grep -n "dir\|port\|cluster-enabled" conf/redis-7000.conf看关键项是不是模板化的。

2.2 配置模板里必须确认的四个参数

不管脚本多自动，有四个参数决定了集群能不能起来，值得逐个核对：

常见做法是脚本用sed在模板里替换端口占位符，生成六份配置。你可以手动验证一下替换是否干净：

# 检查生成的配置里端口和集群配置文件是否一一对应 for p in 7000 7001 7002 7003 7004 7005; do echo "=== port $p ===" grep -E "^port|^cluster-config-file|^dir" conf/redis-$p.conf done

逻辑说明：循环打印每个实例的端口、集群配置文件名和数据目录，确认没有两个实例指向同一个cluster-config-file或同一个dir。参数说明：^port锚定行首避免匹配到注释；dir是数据落盘目录，六个实例必须分开，否则 RDB/AOF 文件会打架。这一步花不了一分钟，但能挡掉后面最玄学的「集群建好了但节点一直 handshake」问题。

3. 执行部署脚本：从环境检查到集群握手的完整链路

3.1 运行前的环境准备与依赖确认

脚本第一段通常是环境检查，但不同发行版和最小化安装的 CentOS 缺的东西不一样。我一般先手动把依赖补齐，再让脚本跑，避免它中途因为缺gcc或tcl中断：

# CentOS 7/8 通用依赖，编译和测试都需要 yum install -y gcc make tcl wget tar # 如果脚本走在线下载，确认网络能到下载源；离线包则跳过 ls -lh redis-*.tar.gz 2>/dev/null || echo "无离线包，脚本将尝试在线获取"

逻辑说明：gcc和make是编译 Redis 源码用的，tcl是make test需要的，缺了会在编译后阶段报错。参数说明：-y自动确认，适合脚本化；2>/dev/null把「文件不存在」的报错吞掉，用后面的 echo 给出可读提示。注意：如果这台机器之前装过旧版 Redis，/usr/local/bin/redis-server可能已存在，脚本若直接覆盖会留下版本混乱，建议先which redis-server确认。

3.2 主脚本执行与关键输出解读

依赖就绪后执行主入口。我习惯加bash -x或者先看脚本头部有没有set -e，前者能打印每条命令，后者决定出错是否立即停止：

# 先干跑一遍看流程（如果脚本支持 --dry-run），否则直接执行并记录日志 bash install.sh 2>&1 | tee deploy.log

逻辑说明：2>&1把标准错误合并到标准输出，tee同时写日志和屏幕，出问题能回查。参数说明：如果脚本没有--dry-run，至少用tee留痕。执行过程中重点盯三个输出节点：一是编译完成后的redis-server --version，确认版本；二是六个实例的redis-server进程是否都起来，用ps -ef | grep redis | wc -l应该是 6；三是集群创建阶段的>>> Performing hash slots allocation和最后的[OK] All 16384 slots covered。

如果卡在Waiting for the cluster to join，八成是端口没通。集群不仅用 7000-7005 这六个业务端口，还会用「端口 + 10000」做集群总线通信，也就是 17000-17005。防火墙或安全组只放业务端口是常见翻车点：

# 查看集群总线端口是否监听 ss -tlnp | grep -E "1700[0-5]" # 临时放行（测试环境），生产按需收紧 firewall-cmd --add-port=7000-7005/tcp --add-port=17000-17005/tcp firewall-cmd --reload

逻辑说明：ss -tlnp列出 TCP 监听端口和对应进程，确认 17000 段存在。参数说明：--add-port支持区间写法，一次放行两段；--reload让规则生效。这一步做完再重跑集群创建脚本，通常就能握手成功。

3.3 集群状态验证：别只看「创建成功」

脚本打印All 16384 slots covered只代表槽位分配完了，不代表集群健康。我一般用三条命令交叉验证：

# 1. 集群整体状态，看 cluster_state 是否为 ok redis-cli -p 7000 cluster info | grep -E "cluster_state|cluster_slots_assigned|cluster_known_nodes" # 2. 节点角色，确认三主三从 redis-cli -p 7000 cluster nodes | awk '{print $2, $3, $9}' | sort # 3. 实际读写，验证槽位路由 redis-cli -c -p 7000 set foo bar && redis-cli -c -p 7000 get foo

逻辑说明：第一条看cluster_state:ok和cluster_known_nodes:6；第二条的awk取节点 ID、地址、角色三列，应该看到三个 master 三个 slave；第三条的-c开启集群重定向，set foo bar会被路由到正确节点。参数说明：cluster_slots_assigned必须是 16384，少一个都说明有槽位没分配。三条都过了，这个集群才算真能用。

4. 避坑与排查：一键脚本最容易翻车的五个地方

4.1 现象：集群创建报Node is not empty

原因：目标实例的dir目录里残留了上一次的nodes-*.conf或dump.rdb，Redis 启动时加载了旧拓扑。解决：停掉所有实例，清空各自数据目录再重来。

# 停实例后清理残留 pkill redis-server for p in 7000 7001 7002 7003 7004 7005; do rm -rf /data/redis/$p/nodes-*.conf /data/redis/$p/dump.rdb /data/redis/$p/appendonly.aof done

4.2 现象：cluster_state:fail，槽位显示0 assigned

原因：--cluster create执行时某个节点没起来，或者cluster-enabled没生效。解决：先redis-cli -p 7000 info cluster确认cluster_enabled:1，再检查六个进程是否都在。缺进程就单独拉起那个实例看日志。

4.3 现象：从节点一直connecting，不复制主节点

原因：主从之间网络不通，或者masterauth没配。如果主节点设了密码而从节点配置里没写masterauth，复制就建不起来。解决：在从节点配置里补masterauth <密码>和requirepass <密码>，重启从节点。

4.4 现象：脚本在 CentOS 8 上编译报jemalloc相关错误

原因：CentOS 8 默认的gcc版本和 Redis 源码里 jemalloc 的兼容问题。解决：make MALLOC=libc跳过 jemalloc，或者升级gcc。脚本如果写死了make，手动改一下编译参数。

4.5 现象：换台机器执行，路径全错

原因：脚本里用了绝对路径且没做变量化。解决：执行前grep -rn "/data/redis\|/usr/local" install.sh conf/把所有硬编码路径找出来，改成基于$(pwd)或环境变量的相对路径。这是复用脚本时最该做的第一件事。

5. 把脚本改造成可复用模板：参数外置与多环境切换

一键脚本最大的价值不是「跑一次」，而是「改一改能反复跑」。我拿到这类脚本后，第一件事是把端口、数据目录、密码、节点数量抽成变量，放在文件头部，这样同一份脚本能在测试和生产之间切换。

# 在 install.sh 顶部加一段可覆盖的配置区 : "${REDIS_PORT_BASE:=7000}" # 起始端口，默认 7000 : "${REDIS_NODE_COUNT:=6}" # 节点总数，必须是偶数 : "${REDIS_DATA_DIR:=/data/redis}" # 数据根目录 : "${REDIS_PASSWORD:=}" # 空表示不设密码 export REDIS_PORT_BASE REDIS_NODE_COUNT REDIS_DATA_DIR REDIS_PASSWORD

逻辑说明：${VAR:=default}的写法表示「如果环境变量没设就用默认值」，这样既能在命令行REDIS_PORT_BASE=8000 bash install.sh覆盖，也能直接跑用默认。参数说明：REDIS_NODE_COUNT必须是偶数，因为集群要主从配对；REDIS_PASSWORD为空时脚本应跳过requirepass相关配置，避免生成空密码指令导致启动失败。

改完之后，验证方法很简单：用两组不同参数各跑一次，看生成的配置和集群状态是否隔离。

# 第一组：默认 7000 起，无密码 bash install.sh && redis-cli -p 7000 cluster info | grep cluster_state # 第二组：8000 起，带密码，跑完先停掉第一组避免端口冲突 pkill redis-server REDIS_PORT_BASE=8000 REDIS_PASSWORD=test123 bash install.sh redis-cli -p 8000 -a test123 cluster info | grep cluster_state

逻辑说明：两组参数跑完都能看到cluster_state:ok，说明参数外置生效且没有互相污染。参数说明：-a传密码，注意命令行带密码会有历史记录泄露风险，生产环境建议用REDISCLI_AUTH环境变量代替。

从那以后我每次拿到这类一键脚本，都强制先做三件事：看目录结构确认没有硬编码路径、手动核对四个集群关键参数、用两组参数各跑一遍验证可复用性。这套习惯帮我挡掉过好几次「在 A 机器好好的、到 B 机器就崩」的尴尬。希望这份拆解能帮你把这个脚本真正用起来，而不是解压完就放在那儿吃灰。

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