简介面向需要在CentOS 7.x环境中快速搭建Redis集群的运维人员与开发工程师该资源提供一套基于Docker的一键部署Shell脚本方案调用者只需按说明传递参数即可自动完成镜像加载、节点创建与集群初始化大幅降低手动配置成本。压缩包共6个文件涵盖多用途Shell部署脚本、Redis配置文件、离线镜像包与Markdown使用文档整体仅22.46MB其中自动构建脚本与备用构建脚本可适应不同部署环境卸载脚本方便清理还原离线镜像则破除网络限制适合内网或离线场景。说明文档对脚本参数、执行顺序及常见用法做了整理能帮助使用者快速上手并理解整个部署流程。目前已有1055人学习下载资源经上传者亲测可用尤其适合需要频繁搭建或验证Redis集群的中高级Linux使用者可显著提升环境准备效率。1. Docker 一键部署 Redis 集群这套 CentOS 7 脚本到底怎么用、值不值得下手动部署 3 主 3 从的 Redis 集群在 CentOS 7.x 上通常要耗掉半个多小时拉镜像、写六份 redis.conf、起容器、挨个节点执行 CLUSTER MEET、再手工分配 hash slot。这套 docker redis 集群 shell 脚本的价值就是把前半段全部压成一条命令后半段用 redis-cli --cluster create 自动完成槽位分配适用对象就是 CentOS 7.x Docker 的 linux 服务器。初次拿到它的人在测试机上跑通 3 主 3 从集群前后不到一支烟的时间中间不需要任何手工交互。适合两类人一是自己维护服务器、想快速拿到一套可用于开发压测集群的从业者二是后端开发想在本机复现集群故障场景又不想把精力耗在环境搭建上。需要先说明边界它解决的是标准三主三从集群的初始化跨机房网络抖动、自动化扩容这些事还得靠其他手段。2. 前置环境与网络选型host 网络、固定 IP 与端口规划2.1 环境基线检查内核、Docker 版本与防火墙拿到资源先别急着执行脚本开头通常会有一段环境检查逻辑先把基础环境过一遍再往下走。我一般会先手动跑这几条命令确认基线cat /etc/redhat-release uname -r docker version --format {{.Server.Version}} systemctl status docker --no-pager逻辑说明第一条确认系统大版本第二条看内核版本第三条拿 Docker 服务端版本号第四条看 Docker 服务有没有真正跑起来。脚本内置的环境检查基本就是把这四步的结果做字符串匹配版本不对直接退出并提示。参数说明CentOS 7.6 以下的内核是 3.10.xDocker 建议 20.10 以上新版 Docker 引擎在 iptables 规则和 bridge 网络处理上明显比老版本稳定CentOS 7 上我不想折腾内核直接升 Docker 收益更高、风险更小。防火墙这块在 host 网络下尤其重要Redis Cluster 节点之间走 TCP 直连除了数据端口还必须放行端口 10000 的总线端口否则集群创建阶段会卡在握手超时。常见做法是提前把规划范围内的端口一次性放行避免后面排错时来回折腾firewall-cmd --zonepublic --add-port6379/tcp --permanent firewall-cmd --zonepublic --add-port6380/tcp --permanent firewall-cmd --zonepublic --add-port16379/tcp --permanent firewall-cmd --zonepublic --add-port16380/tcp --permanent firewall-cmd --reload这条命令分别放行了两个实例的数据端口以及对应的 bus 端口。需要注意的是Redis Cluster 的 bus 端口默认是数据端口加 100006379 对应 163796380 对应 16380只放行数据端口一定会翻车。2.2 为什么用 host 网络而不是 bridge 端口映射这个选择背后是 Redis Cluster 的通信结构决定的。一个集群节点同时监听两个端口数据端口用于客户端读写cluster bus 端口用于节点间 gossip 通信和故障检测bus 端口默认等于数据端口 10000。如果拿 Docker 的 bridge 模式做端口映射每个容器至少得映射两个端口还要处理容器 IP 和宿主机 IP 不一致的问题。bridge 模式最典型的翻车现场gossip 消息里广播的是容器 IP比如 172.17.0.2其他服务器上的节点拿着这个地址去连路由直接失败结果表现为节点能握手但主从切换时连不上目标节点。而 host 网络下容器直接复用宿主机网络栈Redis 对外广播的地址就是宿主机真实 IP链路少一层转换故障面小很多。对比项bridge 端口映射host 网络端口暴露每个容器至少映射两个端口直接监听宿主机端口gossip 源 IP容器 IP常不可被其他服务器路由宿主机真实 IPbus 端口管理需要手动核对映射关系直接按配置监听跨服务器部署要处理 announce-ip 与映射地址只需把 announce-ip 配成真实 IP脚本复杂度高低所以这个脚本默认走 host 网络不是偷懒而是它能在“可预测”和“可排错”之间取得最佳平衡。host 网络唯一需要付出的代价是端口规划要严格不能让两个实例的端口跟其他服务冲突。2.3 节点清单与 redis.conf 模板的填充变量脚本拿到手后真正有技术含量的部分在 redis.conf 模板和节点清单的配合方式。目录结构一般是每个实例一个 conf 目录和一个 data 目录redis.conf 由脚本按模板生成数据目录按实例序号隔离。核心模板长这样port 6379 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes daemonize no cluster-announce-ip 192.168.1.20 cluster-announce-port 6379 cluster-announce-bus-port 16379逻辑说明cluster-enabled yes 让 Redis 以集群模式启动不写这一项后面的 cluster create 全部白搭cluster-config-file 指定集群元数据文件位置由节点自动维护不需要人工编辑appendonly yes 开启 AOF 持久化这关系到重启后槽位和主从关系能否恢复cluster-announce-ip 和两个 announce 端口是 host 网络下必须手填的直接决定了其他节点和客户端拿到的地址。参数说明cluster-node-timeout 5000 表示 5 秒内收不到某一节点的响应就认为该节点可能故障会进入客观下线判定流程。生产网络抖动明显的时候可以把这个值调到 10000防止瞬时丢包误触发主从切换。cluster-announce-ip 不建议写作 127.0.0.1那会让集群只能在单机内自嗨跨服务器部署必坑。如果是三台服务器每台各跑两个实例节点清单里同一个 IP 就会重复出现两次分别配两个不同端口如果只是单机演练三个 IP 都写 127.0.0.1 也能建集群但客户端访问方式就得通过本机端口来连。3. 脚本结构拆解从容器循环创建到 cluster create 的调用链3.1 节点循环创建目录、配置文件与容器启动脚本的主体是一个 create_node 函数循环拉起来所有容器。这段设计得比较规整核心逻辑可以认为是下面这样IP_LIST(192.168.1.20 192.168.1.21 192.168.1.22) REDIS_PORT(6379 6380 6379 6380 6379 6380) BASE_DIR/opt/redis-cluster IMAGEredis:6.2 create_node() { local node_ip$1 local node_port$2 local idx$3 mkdir -p ${BASE_DIR}/${idx}/data ${BASE_DIR}/${idx}/conf docker rm -f redis-${idx} /dev/null 21 docker run -d --name redis-${idx} --network host \ --restart unless-stopped \ -v ${BASE_DIR}/${idx}/data:/data \ -v ${BASE_DIR}/${idx}/conf/redis.conf:/usr/local/etc/redis/redis.conf \ ${IMAGE} redis-server /usr/local/etc/redis/redis.conf }逻辑说明先建数据中心和配置目录再强制删除可能残留的同名容器保证脚本重复执行不会因为容器名冲突中断最后用 docker run 启动。redis-server 后面跟的路径是容器内配置文件的绝对路径脚本故意把它指定到 /usr/local/etc/redis/redis.conf覆盖官方镜像的默认配置入口。参数说明--network host 是前面讲的网络方案--restart unless-stopped 保证宿主机重启后容器自动拉起这对集群自愈至关重要少了这一项机器重启后你还得来手动 docker start三个挂载路径把配置和数据都落到宿主机磁盘容器删了重建数据不丢。这个函数被调用时脚本会用下标遍历 IP_LIST 和 REDIS_PORT 两个数组同时为每个实例生成对应的 redis.conf。生成动作放在 mkdir 之后、 docker run 之前目的是确保每个容器拿到的配置实例专属不会存在共享一份配置的情况。3.2 集群初始化命令redis-cli --cluster create 的参数含义六个容器都起来后脚本进入最关键一步执行 cluster create。这一步负责把零散节点拉成集群并完成槽位分配redis-cli --cluster create \ 192.168.1.20:6379 192.168.1.20:6380 \ 192.168.1.21:6379 192.168.1.21:6380 \ 192.168.1.22:6379 192.168.1.22:6380 \ --cluster-replicas 1 \ --cluster-yes逻辑说明redis-cli --cluster create 会把后面所有节点依次做 cluster meet然后根据节点总数和副本数自动计算槽位划分。这里三对节点每对都是同一台服务器的两个实例跨服务器互为副本主从不会落在同一台物理机上这样任意一台服务器宕机整集群仍有完整副本可用。参数说明--cluster-replicas 1 的意思是每个主节点分配 1 个从节点三主三从一共六个实例如果想做三主六从就把这个值改成 2同时把 IP_LIST 和 REDIS_PORT 扩充到九个。--cluster-yes 跳过槽位分配的交互确认。槽位分配是自动完成的16384 个 hash slot 被切成三段分别给三个主节点从节点不持有槽位。脚本没有手动执行 CLUSTER MEET因为 create 子命令已经内置了这一动作这也是它能压缩部署时间的关键。3.3 等待端口就绪与重试逻辑直接跑 create 有个常见问题容器刚启动时 Redis 进程可能还没完成监听这时候 create 会报连接失败。脚本里通常会加一段等待循环for i in ${!REDIS_PORT[]}; do node_ip${IP_LIST[$((i/2))]} node_port${REDIS_PORT[$i]} while ! nc -z ${node_ip} ${node_port}; do sleep 1 done done逻辑说明nc -z 检查 TCP 端口是否可连连不上就每秒重试一次直到所有端口都接受连接才继续。这比固定 sleep 5 可靠得多因为容器拉镜像、加载 RDB / AOF 的耗时并不稳定固定等待时间要么浪费要么不够。参数说明这里用了一个数组下标映射技巧i/2 是整数除法把 0 和 1 都映射到 IP_LIST[0]正好对应同一台服务器上的两个实例。如果你的资源配置是每台服务器三个实例要把除数改成 3。有些版本的脚本还会在等待完端口后补一个 PING 探测确认 Redis 真正进入可服务状态。正常情况下这段等待在全新环境里耗时很短。4. 部署执行清单改三个变量、跑一次脚本、用 cluster info 验收4.1 修改脚本顶部变量节点 IP 与端口规划拿到脚本后第一个要动的地方是文件顶部的变量区。这一段的注释通常写得很直白照着改就行# 按实际部署环境修改 IP_LIST(192.168.1.20 192.168.1.21 192.168.1.22) REDIS_PORT(6379 6380 6379 6380 6379 6380) BASE_DIR/opt/redis-cluster IMAGEredis:6.2改动前先想清楚拓扑三台服务器、每台两个实例共六个节点这是标准三主三从。IP_LIST 只写三台机器的 IP但 REDIS_PORT 写六个端口两个数组长度比是 1 比 2脚本就是按这个比例把同 IP 的两个端口当成一对。如果你要在一台机器上模拟整个集群IP_LIST 就写成同一个 IP 重复三次比如 192.168.1.20 写三遍端口仍按六个数排。要注意生产环境不要这么干主从落在同一台机器上就等于没有高可用。BASE_DIR 是集群数据在宿主机上的根目录每个实例会在其下建立序号目录。IMAGE 字段建议固定一个具体版本比如 redis:6.2别用 latest省得哪天拉到一个大版本镜像行为发生变化。4.2 执行脚本日志重定向与执行过程观察环境变量改好后执行方式建议加上日志重定向尤其是首次部署cd /opt/redis-cluster bash redis-cluster-deploy.sh deploy.log 21 tail -f deploy.log逻辑说明脚本执行到 redis-cli --cluster create 时会自动处理交互确认不需要你守在终端前敲 yes。把输出重定向到日志文件一是防止终端会话断开导致输出丢失二是后面排错时有完整过程可查。观察重点有三个第一有没有出现 bind: address already in use第二六个容器是否全部进入 Up 状态第三日志末尾有没有 Cluster created 或类似标识。前两个对应端口占用和容器启动失败第三个才是真正的成功标志。常见做法是执行后等到脚本自然退出再用下面的验证命令做多重确认。不建议在脚本还在等待端口的时候就另起一个终端去操作可能会打断它的状态判断。4.3 验收动作cluster info 与 cluster nodes 的输出解读脚本跑完后必须用一个动作确认集群真的可用我的习惯是连续看两个输出redis-cli -p 6379 cluster info redis-cli -p 6379 cluster nodes第一个命令的输出里重点看这几行cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_known_nodes:6 cluster_size:3cluster_state 是 ok 而不是 fail说明槽位分配完成cluster_slots_assigned 等于 16384 说明没有空槽cluster_known_nodes 显示 6和物理节点数对得上。cluster nodes 的输出则是看主从关系和 fail 标记。正常情况下每台服务器上各有一个 master 和一个 slavemaster 的 flags 栏显示 masterslave 的 flags 栏显示 slave而且主从不会出现在同一台物理机上。如果看到某个节点 flags 里有 fail 或 pfail集群状态多半不是真健康需要回到日志里找原因。4.4 这份脚本没有替你做的三件事脚本解决了初始化但有三件事它默认不管部署完要自己补。第一是节点内存上限没配 maxmemory 的话Redis 在极端写入下可能会把宿主机内存吃爆建议按实例内存给 redis.conf 模板追加 maxmemory 配置。第二是监控容器本身的 CPU、内存、磁盘指标不在脚本范围内上了生产环境要靠外部监控去盯。第三是跨机房的网络隔离脚本按一个局域网场景设计跨机房抖动和延迟可能导致集群频繁判主节点下线。另外提醒一句不要手动编辑 nodes.conf 或 redis.conf 里的集群元数据节点间的状态以集群学到的 gossip 信息为准手动改文件只会造成状态不一致。5. 避坑记录六个最容易遇到又不写进 README 的问题5.1 端口与网络相关的坑现象一脚本执行到 docker run 时报 bind: address already in use容器没起来脚本卡住。原因通常是端口规划时只看了数据端口漏掉了前面提到的 bus 端口。比如 6379 的数据端口空闲但 16379 被别的服务占用容器照样起不来。解决方法是先用 ss -lntp 查看端口占用再把 REDIS_PORT 整体平移或者避开 bus 端口冲突区间移动端口后记得 redis.conf 里 cluster-announce-bus-port 要同步改成新端口加 10000。现象二集群创建成功但 redis-cli --cluster check 或者 failover 时报连接失败错误指向的 IP 是完全不可路由的地址。原因多半是 cluster-announce-ip 没改配置文件里保留着模板里的示例 IP。在 host 网络模式下gossip 消息会广播这个 announce 地址写错的话其他节点拿着假地址来连自然连不上。解决方式是把三台机器 redis.conf 里的 cluster-announce-ip 统一改成各服务器真实内网 IP重新生成配置再执行一次脚本。注意只改一份配置没用六份全要动。现象三跨服务器部署时集群创建过程反复 timeout同一台机器上的两个节点却能正常 meet。原因基本可以锁到防火墙firewalld 没放行 bus 端口。数据端口保证了客户端连接但节点间的 gossip 走的是数据端口加 10000 的通道这个端口被 drop 后节点之间收不到心跳表现为超时和 unstable。解决方法是把规划好的所有数据端口和 bus 端口一次性放行然后 firewall-cmd --reload。现象四客户端从应用服务器连接集群连第一个节点能通但从节点返回 MOVED 指令后客户端转向的那个地址连不上。原因是集群广播的 announce-ip 与客户端所在网络的访问路径不一致比如 announce-ip 配成了内网地址客户端却在另一个网段。解决方法是根据客户端的实际网络位置来决定 announce-ip 写哪个地址客户端和应用如何访问集群announce-ip 就写哪个可通地址。5.2 配置与操作方式的坑现象五宿主机重启后docker ps 显示容器全部 Up但 cluster info 变成 cluster_state:fail槽位大量缺失。原因通常是数据目录没有真正挂载或 appendonly 没开。docker run 没加 -v 的情况下nodes.conf 写在容器可写层里容器一旦被删除重建槽位元数据全部归零。解决方法是确认每个容器都挂载了宿主机 data 目录并且 redis.conf 里 appendonly yes 已生效。判断生效与否进容器看 /data 下有没有 appendonly.aof 文件即可。现象六CentOS 7 的 SELinux 处于 enforcing 状态时容器写挂载目录报 Permission denied。原因是宿主机目录的 SELinux 上下文不是容器可写类型。我惯用的处理方式是执行 chcon -Rt svirt_sandbox_file_t /opt/redis-cluster把整个集群数据目录的上下文改成容器可访问类型。这比直接 setenforce 0 精确不会把整台机器的安全策略关掉。测试机不在乎安全策略的话也可以临时 setenforce 0但生产环境不建议这么做。提示以上坑点的共同根源一半是端口没有系统规划一半是 announce-ip 假设了错误的网络路径。部署前把这两点值画清楚能少走大半弯路。6. 进阶验证主从切换演练与 cluster check 巡检技巧6.1 主从自动切换演练集群建好只是一句开始真正验证它有没有用要模拟主节点宕机一次。我的做法是挑一个 master 容器直接停掉观察它对应的 slave 能不能自动变成 masterdocker stop redis-0 sleep 15 redis-cli -p 6380 cluster nodes | grep -E master|fail原理说明redis-0 被停止后其他节点会在 cluster-node-timeout 时间内探测不到它的心跳然后集群进入客观下线流程它的从节点发起选举过半后自动晋升为新主节点。15 秒的等待时间给足了 5000ms 超时和选举过程。执行后看 cluster nodes 输出如果原来的 slave 变成了 master而且没有节点处于 fail 状态说明集群的故障转移链路是通的。这时候再把停掉的容器启动docker start redis-0它会以旧主的身份回到集群但已经变成新主节点的从节点数据会自动做全量同步。这个动作模拟了实际生产里最常遇到的整机掉电场景。6.2 cluster check 巡检 baseline日常巡检我建议用 redis-cli --cluster check它一次性输出槽位完整性、节点健康状态、主从关系比逐条拼 cluster nodes 方便redis-cli --cluster check 192.168.1.20:6379 --cluster-yes这个命令会给出槽位覆盖、节点数量、每个 master 的 slot 分布、以及是否有 fail 标记。我的习惯是把第一次成功部署后的 check 结果存成 baseline.txt之后的每次巡检都输出一份新结果 diff 一遍。哪一行多出来一个 fail哪一行槽位数量对不上一眼就看清。从那以后我每次用这套脚本部署完集群都强制自己走一遍 docker stop 演练加 check baseline折腾次数多了比对正常输出的效率远高于单独排查节点状态。这也算是一套供同行直接使用的判断习惯希望帮到你。本文还有配套的精品资源点击获取