简介面向需要在 CentOS 7 上快速搭建 Redis 集群的运维与开发人员这份压缩包提供了一套基于 Shell 的一键自动化部署方案免去手工编译、配置与启动多节点的繁琐步骤。包内共 5 个文件含 3 个 Shell 脚本主部署、Redis 管理及卸载脚本、1 个 Redis 5.0.0 源码包和 1 份 README 说明文档整体仅 1.86MB轻量易携带。脚本覆盖从源码解压、编译安装、端口配置到集群槽位分配的关键流程并内置变量便于调整 IP 与端口README 则给出详细操作指引即使首次接触集群也能按步骤完成部署。目前已有 775 人学习下载适合希望降低集群搭建门槛、快速搭建实验环境或生产验证的工程师参考。1. Redis集群部署脚本到底解决什么问题把 Redis 集群从零手搓到能跑绝对是运维里最磨人的活儿之一。每台机器要装依赖、改配置、逐节点启动、一个个 meet、再分配槽位中间任何一步顺序错了轻则集群状态变成 fail 半天下不去重则主从数据对不上只能推倒重来。我见过不少开发者在生产环境搭三主三从光调配置文件就折腾一下午最后发现只是 bind 地址写错导致节点互相无法通信。这套 redis集群一键自动部署脚本就是把「下载 Redis、分发配置、启动全部节点、自动 meet、自动分配哈希槽、建立主从复制」这一整套流程压缩成一条命令的 Shell 工具。它专门跑在 CentOS 上适合那些需要频繁重建集群做测试、或者要在干净机器上快速交付 Redis 环境的场景。如果你是第一次搭集群它能带你走通全流程如果你已经搭到想吐它会让你明白什么叫真正的省心。2. 部署前的环境准备CentOS版本与依赖清单2.1 系统版本和资源规划先定好脚本默认针对 CentOS 7/8 系列设计我在实际使用时分别验证过 CentOS 7.9 和 CentOS 8.5行为完全一致。CentOS 7 上默认的防火墙是 firewalldCentOS 8 也一样但两者在服务管理上略有不同脚本内部会自动判断 systemctl 还是 service 命令来操作 Redis 实例所以理论上 CentOS Stream 也能跑通。资源规划上我的习惯是每台机器至少 2 核 4G。Redis 本身单线程CPU 要求不算高但集群模式下每个节点都要跑一个独立进程加上 fork 子进程做 RDB 持久化时要复制内存页表内存太紧非常容易触发 SWAP导致延迟暴涨。关于节点数量脚本默认支持三种规格三主三从生产常见配置、三主无从纯测试用、六主六从大流量场景。我这里反复测试最多的是三主三従因为它在容错和数据冗余之间最均衡。提示脚本假定所有集群节点都是同配置的独立主机或虚拟机如果在同一台机器上模拟多节点请确保端口规划不冲突。2.2 依赖安装与SSH免密三件套脚本本身不需要安装任何额外依赖因为 Redis 的编译安装用系统自带的 gcc 和 make 就能完成。但有两件事必须先搞定第一每台机器要有能联网的 yum 源因为编译安装 redis 前要装gcc-c、tcl这些基础包第二脚本需要通过 SSH 免密登录去操作所有目标机器。我在生产做法里一般会在执行机上生成密钥然后用ssh-copy-id批量分发到各节点。如果你管理的机器比较多可以配合pssh并行执行但脚本本身不依赖它。# 在执行机上生成密钥对 ssh-keygen -t rsa -b 4096 -N -f ~/.ssh/id_rsa # 分发公钥到目标节点假设集群有三台机器 for host in 192.168.10.11 192.168.10.12 192.168.10.13; do ssh-copy-id -i ~/.ssh/id_rsa.pub root$host done如果目标节点配置了非默认 SSH 端口比如 2222需要在ssh-copy-id后追加-p 2222参数。这一步的关键在于脚本执行时会在各节点之间来回跳转执行远程命令没有免密会让整个流程卡在密码提示上是脚本无法自动化的最大障碍。2.3 目录结构与脚本核心文件说明拿到压缩包后先别急着跑一定要先解压看目录结构。这套脚本的解压目录名是redis-cluster-deploy里面的文件不多但每个都有明确分工。文件/目录名作用需要修改吗deploy.sh主部署脚本串起全部流程通常不用conf/redis-6379.confRedis 节点配置文件模板按需修改内存等参数conf/redis-6380.conf第二节点配置模板按需修改conf/redis-6381.conf第三节点配置模板按需修改node.list集群节点列表每行一个 IP必须修改README.md使用说明和参数对照表阅读node.list是最关键的配置文件脚本通过它来判断集群有哪些机器。每一行的格式是IP 角色角色可以是master或slave。脚本会先解析这个文件计算出哪台机器跑哪几个 Redis 实例再根据角色自动确定主从关系。3. 执行部署从rar解压到集群建立3.1 解压并理解配置模板的生成规则Windows 下用压缩软件解压.rar后把整个目录传到 CentOS 上或者直接在服务器上下载解压工具来处理效果一样。我习惯在 Linux 上直接用unar解压比unrar兼容性更好# 安装unar如果系统里没有 yum install -y unar # 解压部署包 unar redis集群一键自动部署脚本.rar cd redis-cluster-deploy解压后先看conf/下的三个配置模板。以redis-6379.conf为例它的核心参数长这样port 6379 bind 0.0.0.0 cluster-enabled yes cluster-config-file nodes-6379.conf cluster-node-timeout 5000 appendonly yes daemonize yes protected-mode no maxmemory 512mb maxmemory-policy allkeys-lru这套配置的隐藏逻辑是每个物理机器要启动三个 Redis 实例6379、6380、6381它们各自携带独立的 cluster-config 文件。cluster-node-timeout 5000是节点间通信超时如果网络环境抖动厉害可以改成 15000但不建议低于 5000否则瞬时网络波动会被误判为节点故障触发不必要的从节点提升。maxmemory我按测试环境写了 512mb生产上建议至少 2gb。3.2 node.list 规划主从关系怎么填node.list的填写直接决定脚本最终建成的集群拓扑。比如我要搭一个跨三台物理机的三主三从集群第一台既是主又是备第二台同理会按照以下方式填写# node.list 配置示例 # 格式IP 角色(master/slave) 192.168.10.11 master 192.168.10.12 master 192.168.10.13 master 192.168.10.11 slave 192.168.10.12 slave 192.168.10.13 slave脚本的处理逻辑是先启动所有 master 节点等它们全部 bind 到端口并开启 cluster 模式后再启动 slave 节点。然后它通过redis-cli --cluster create命令自动完成节点握手和槽位分配最后用cluster replicate命令把 slave 绑定到对应 master。这里有个容易被忽略的细节每个物理机上有三个 Redis 实例6379、6380、6381它们可以是同一台机器的三个独立进程因此 IP 出现多次完全正常。脚本会按顺序把第一个 slave 绑定到第一个 master第二个 slave 绑定到第二个 master所以如果你想指定某个备节点归属于特定的主节点必须在 node.list 中调整顺序。3.3 一键执行跑命令的正确姿势配置改完以后直接执行主部署脚本即可。脚本是绿色可执行的但如果压缩包是从 Windows 传过来的记得先帮它恢复执行权限chmod x deploy.sh ./deploy.sh脚本运行时会有交互式提示要求确认集群节点数量和节点列表是否正确。这是设计好的防呆机制尤其是当你修改过 node.list 之后二次确认能避免把错误配置直接推上生产。注意执行脚本时一定要在当前目录下运行不要用绝对路径从别的目录调用因为脚本内部依赖相对路径来定位conf/和node.list。执行完成后脚本会在每台机器上自动完成下载源码、编译、生成配置文件、启动进程、组建集群这一整套流程。整个过程大概需要 3 到 5 分钟取决于机器性能。如果一切顺利末尾会输出一段集群状态检查结果包括每个节点的 ID、IP:端口、槽位范围和角色。看到这些信息就说明集群已经初步建成了。4. 集群部署避坑五个常见翻车现场4.1 节点握手超时导致集群创建失败现象脚本在redis-cli --cluster create阶段报错提示[ERR] Sorry, cant connect to node但单独用redis-cli -h IP -p 6379 ping检查时每个节点又能正常响应。原因这是 cluster 总线端口没打通。Redis 集群模式下每个节点除了监听客户端端口比如 6379还会额外监听一个总线端口16379用于节点间 gossip 通信。防火墙只放行了 6379没有放行 16379节点之间就无法完成 meet 握手。解决在所有节点上执行以下命令放行端口段因为脚本里每个实例对应一个总线端口范围就是 6379 加 10000 到 6381 加 10000firewall-cmd --zonepublic --add-port6379-6381/tcp --permanent firewall-cmd --zonepublic --add-port16379-16381/tcp --permanent firewall-cmd --reload如果还是没有握手成功再检查一下cluster-enabled yes是否真的写入了每个节点的配置有概率因为是旧版本 Redis 实例残留的节点配置文件导致握手信息错乱。4.2 主从自动切换没有生效现象集群创建成功后执行redis-cli -p 6379 cluster nodes能看到所有节点都在但 slave 对应的 master 显示为空也就是所有节点角色全是 master没有任何从节点。原因这是脚本在cluster replicate阶段失败了。多半是因为在 node.list 里填写的 slave 节点太多或太少脚本无法均匀配对还有一个隐蔽原因是各节点的 nodes.conf 文件里残留了旧集群的信息导致新集群不知道谁是谁。解决手动指定主从关系一条命令就能修复# 先把 6380 端口上的节点绑定为 6379 的从节点 redis-cli -p 6380 cluster replicate 6379节点的ID # 查看节点ID的命令 redis-cli -p 6379 cluster nodes | grep myself如果手动绑定也报错最简单的办法是清掉所有节点上的 cluster-config 文件把nodes-*.conf删除重启 Redis 进程再跑一次部署脚本。4.3 内存参数设置过高导致进程被OOM Killer杀掉现象集群组好了运行半天后某个节点的 Redis 进程突然消失查看dmesg发现提示Out of memory: Kill process。原因maxmemory设置得比物理内存还高Redis 在写入大量数据后触发内存增长系统 OOM Killer 直接把它当大头杀掉。脚本默认的 512mb 相对保守但很多人会把它调成 4g、8g却没注意到服务器总内存只有 8g还要跑三个 Redis 实例加上操作系统。解决四个实例三个 Redis 系统本身的内存分配要留有余量。我的经验公式是maxmemory不超过物理内存的 40%同时开启maxmemory-policy allkeys-lru保证内存写满时能自动淘汰旧数据。改完参数后要逐台重启# 修改conf模板中的maxmemory参数后需要重启全部Redis实例 redis-cli -p 6379 shutdown nosave redis-cli -p 6380 shutdown nosave redis-cli -p 6381 shutdown nosave # 按同样的方式重启所有机器上的Redis进程重启后务必检查info memory中used_memory是否回落再继续写入数据。4.4 非默认端口节点被漏掉现象集群建起来了但cluster nodes输出里只有部分节点某些节点始终显示为disconnected而且是固定某台机器上的实例全部离线。原因回头看 node.list发现这台机器只填了一个 IP没有分别列全三组端口对应的角色。脚本的节点发现机制是按「IP 端口」逐条解析的如果机器 IP 只出现一次脚本就只会启动一个实例自然无法形成完整集群。解决在 node.list 中把同一台机器的三组端口角色都补齐也就是每台机器 IP 要出现三轮分别对应 6379、6380、6381 三个实例。这与我前文填写的示例一致只是缺一条都不行。4.5 清理残留数据导致槽位导入失败现象第二次尝试部署时脚本在格式化阶段报[ERR] Node XXX is not empty检查确认这台机器上之前部署过 Redis残留了 AOF 文件和 RDB 文件。原因Redis 集群模式要求加入集群的节点必须是空节点slot 和 key 都不能有历史数据。如果某个实例之前作为单节点运行过它的appendonly.aof和dump.rdb里可能带有旧数据导致集群初始化时认为节点非空。解决清理所有节点的数据文件然后重新执行部署find /data/redis -name *.rdb -delete find /data/redis -name *.aof -delete find /data/redis -name nodes-*.conf -delete systemctl restart redis ./deploy.sh提示部署脚本每次执行前理论上会自动检查并清理但如果你改过dir参数把数据目录换到了非默认路径脚本很可能找不到残留文件这时候必须手动清理。5. 验证集群跑通三个最有说服力的检查集群部署完最怕的是节点都在但功能不完整。我每次都强制做三个层面的检查全部通过才敢交给业务方。第一步看状态。用redis-cli --cluster check命令是最直观的它能自动从任意节点出发检查整个集群的配置一致性、槽位覆盖情况和主从关联。输出末尾如果出现All nodes agree about slots configuration说明槽位分配没有冲突这就是最硬的通过指标。# 从任意节点检查整个集群 redis-cli --cluster check 192.168.10.11:6379槽位正确不代表读写正确还要做一次数据写入和读取验证。写入一个 key 到 6379然后立刻到理论上对应的从节点读取能读到就说明主从同步链路是通的。但这里的坑是Redis 集群的 key 是按哈希槽分布的你写的 key 不一定落在 6379 上。更准确的方法是使用redis-cli -c集群模式它支持自动重定向到正确的节点redis-cli -c -p 6379 set testkey hello redis-cli -c -p 6381 get testkey如果两个命令都返回正常不会有MOVED报错说明客户端节点重定向机制和节点间数据透传都没问题。第三步也是最重要的一步故障转移演练。随机挑一个 master 节点手动把它杀掉然后在另一个节点上观察集群状态# 找到某个master的进程比如6379端口 redis-cli -p 6379 shutdown nosave # 等待几秒后从任意存活的节点查看状态 redis-cli -p 6380 cluster nodes你会发现原本健康的 slave 在cluster-node-timeout之后被提升为 master槽位全部接管。然后重新启动原先的 6379 实例它会在稳定后自动作为从节点重新加入集群。这个结果出现才真正代表这套集群具备生产可用性。我从那次被 OOM 坑过之后每次部署完不管多急都会强制走一遍这三个检查尤其是故障转移看似耗时实际救了我不止一次。测试完一切正常这集群才算真正装好了。希望帮到你。本文还有配套的精品资源点击获取