简介面向需要在 CentOS 7.x 上快速搭建 Redis 集群的运维与开发人员这份资源以 shell 脚本实现了 Docker 环境下的一键部署只需按 README 说明将参数传递给安装脚本即可自动完成镜像加载、节点创建与集群初始化等步骤实测可用。压缩包共含 6 个文件以 sh 脚本为主涵盖部署、卸载与辅助构建三个环节另附 redis.conf 配置模板、redis_docker_images_latest.tar 离线镜像包和 markdown 格式的说明文档整体约 22.46MB。目前已有 1055 人学习下载。通过阅读脚本可理解基于 Docker 的 Redis 集群搭建流程与参数化设计思路也能直接复用或按需调整免去手工逐节点配置的繁琐与排错成本。1. 一键部署Redis集群为什么shell脚本才是CentOS 7上的最优解手动搭建Redis集群是个体力活先把6份redis.conf的端口、总线端口、持久化路径逐项改好再逐个启动容器最后还要敲几十条meet、replicate和addslots命令。任何一步IP写错或端口被占用集群状态就卡在fail排查起来让人头疼。这套流程放在CentOS 7.x上尤其繁琐——旧内核、老版本docker都对网络模式有约束没有脚本兜底很容易翻车。所谓docker一键部署redis集群shell脚本就是把配置生成、容器创建、网络分配、节点握手、主从绑定、槽位分配这六个环节全部收敛到一个可重复执行的脚本里。这一步到位的能力对两类人价值最大一类是需要在测试环境频繁重建集群验证业务逻辑的开发者另一类是生产环境交付前需要快速铺多个独立集群的运维。脚本解决的不只是省时间更重要的是消除人工操作的不确定性——同样的参数跑十次结果必须一致。2. Redis集群的容器化选型固定IP、总线端口与脚本要跨过的三道坎2.1 三种部署方式对比为什么不用docker-compose在CentOS 7.x上把Redis集群容器化常见做法有三种纯docker命令裸跑、docker-compose编排、shell脚本自动化。三者各有边界但针对多个节点组成一个集群这个诉求shell脚本反而是最省心的解。部署方式配置管理粒度固定IP支持故障恢复适用场景纯docker命令单容器需手动指定需人工介入临时验证单节点docker-compose多容器支持但需写死IP需配合外部脚本有固定拓扑的标准化部署shell脚本批量生成与统一操作主动分配并写入配置可内建健康检查多节点集群的反复重建docker-compose适合服务集合的编排比如一个Web应用带一个Redis单节点。但Redis集群是多实例状态内联的拓扑节点之间需要双向发现compose文件里每个服务都要写独立IP、独立端口映射写出来的文件比shell脚本还要啰嗦。而且compose在CentOS 7上的旧版本对自定义网络的支持有差异一旦涉及动态节点数量调整脚本的for循环明显更灵活。2.2 集群创建流程从配置文件生成到槽位分配Redis集群从空壳到可用的完整链路分四步生成配置、启动实例、节点握手、分配槽位。脚本的价值不是替代redis-trib或redis-cli的集群命令而是把前三步重复劳动自动化最后一步用命令一键触发。配置生成阶段每个节点需要独立的port、cluster-config-file、appendonly路径但这些参数除了端口其余高度相似用函数生成模板最合适。启动实例阶段要处理容器数量和网络互通的问题。节点握手阶段Redis 5.0之后可以直接用redis-cli --cluster create自动完成meet和主从分配但前提是节点之间路由可达、端口开放。槽位分配是这个命令内部完成的包含主节点的16384个槽和从节点的replicate绑定。脚本要控制的变量就清楚了每个节点的IP、端口、总线端口端口10000、主从配对方式。其中总线端口最容易被忽略——Redis集群节点间通信用的是port10000的端口容器端口映射漏掉它节点能启动但永远无法完成meet握手。2.3 网络模式与端口映射脚本要解决的三个硬问题CentOS 7.x上给Redis集群容器选网络模式绕不开三个问题容器IP漂移、总线端口暴露、宿主机端口占用。隔离这三个问题就握住了脚本设计的关键。第一个问题是容器IP漂移。默认bridge模式下容器每次重启IP都会变化而Redis集群的nodes.conf里记录的是节点启动时的IP一旦变了集群就认为节点断开。解法是创建自定义bridge网络并手动指定静态IP脚本里用docker run --ip显式分配。第二个问题是总线端口。即使容器IP固定如果宿主机访问不到端口映射后的总线端口节点之间还是会握手失败。端口映射要同时覆盖数据端口和总线端口两个端口总共6个节点就要映射12个端口脚本里用同一份端口列表循环生成映射参数最稳妥。第三个问题是端口占用的冲突排查。生产环境里6000-6010和16000-16010这两段经常被其他中间件占用脚本最好支持从外部传入起始端口而不是硬编码这样遇到冲突时改一行启动参数就能换一段干净端口。3. 编写一键部署脚本从配置模板到cluster create3.1 脚本骨架变量定义与配置生成函数写脚本前先把变量拆成使用者可调和脚本内部使用两组。使用者可调的部分是节点数量、起始端口、Redis镜像版本、网络网段内部使用的部分是IP列表、端口列表、配置文件名。这样设计的好处是将来调整集群规模时不需要改动逻辑代码。#!/bin/bash # 可调参数区域 REDIS_IMAGEredis:7.0-alpine # 镜像按需更换测试环境用alpine版启动更快 BASE_PORT7001 # 起始数据端口总线端口自动10000 NODE_COUNT6 # 节点总数生产建议至少6个 NET_NAMEredis-cluster-net # 自定义网络名 NET_SUBNET172.30.0.0/16 # 网段避免与公司现有网段冲突 START_IP172.30.0.10 # 容器起始IP配合递增逻辑分配 # 内部变量区域 PORTS() IPS() TOTAL0逻辑说明镜像用alpine版本主要是为了减少拉取时间和容器体积实测同一台机器跑6个alpine容器比debian版的Redis容器少占约600MB内存。网段必须手动指定不能依赖docker自动分配的默认段否则宿主机已有的容器网络可能冲突。注意NODE_COUNT设定为6是最小集群配置3主3从少于6个脚本应直接退出提示防止建立一个没有故障转移能力的假集群。参数说明START_IP决定了容器IP的起点脚本后续按顺序递增。如果你在开发环境已经有别的容器占了这个网段把这个起始IP往后挪即可。Redis版本建议选带cluster支持的稳定版太老的版本对总线的处理方式不同脚本里--cluster create的参数兼容性会有差异。3.2 配置文件生成用一份模板渲染出多份conf配置生成这一步的要点是统一基础配置差异化端口类参数。不要为每个节点手写完整conf而是通过cat模板配合变量替换一次性生成。下面代码把公共参数和差异参数分开处理避免漏改。generate_conf() { local idx$1 local port$2 local dir/data/redis-cluster/conf/redis-${port}.conf mkdir -p $(dirname $dir) cat $dir EOF port ${port} cluster-enabled yes cluster-config-file nodes-${port}.conf cluster-node-timeout 5000 appendonly yes daemonize no protected-mode no bind 0.0.0.0 EOF }逻辑说明配置文件里的bind 0.0.0.0是关键——容器内的Redis默认只绑定本地回环地址如果这里不放开跨容器的节点握手必然失败。cluster-config-file为每个节点独立命名避免多个容器共享同一个data目录时互相覆盖文件。cluster-node-timeout设为5000毫秒是经验值设太短网络抖动就会被误判为主节点下线触发不必要的故障迁移。参数说明这段模板中没有指定cluster-announce-ip这是有意为之——在自定义bridge网络里手动指定了容器IP且没有做NAT映射Redis可以自动识别自己的IP。如果后续改成端口映射模式比如容器在远程宿主机就必须在模板里追加cluster-announce-ip为宿主机IP这一点会在避坑章节详解。3.3 启动容器与健康检查等待就绪而非盲目sleep启动容器不能一把梭直接建集群必须等所有节点进入集群待命状态。常见做法是循环执行redis-cli -p PORT cluster info从返回结果里判断cluster_state不再是fail后才继续。sleep固定秒数也算方案但对老机器不友好——配置生成慢、容器启动慢很容易在还没就绪时就执行建集群命令。start_container() { local idx$1 local ip$2 local port$3 docker run -d \ --name redis-node-${idx} \ --network ${NET_NAME} \ --ip ${ip} \ -p ${port}:${port} -p $((port10000)):$((port10000)) \ -v /data/redis-cluster/conf/redis-${port}.conf:/usr/local/etc/redis/redis.conf \ ${REDIS_IMAGE} \ redis-server /usr/local/etc/redis/redis.conf } wait_for_cluster_ready() { local ready0 for _ in $(seq 1 30); do ready0 for port in ${PORTS[]}; do info$(docker exec redis-node-1 redis-cli -p ${port} cluster info 2/dev/null) if echo $info | grep -q cluster_state:ok; then ready$((ready1)) fi done [ $ready -eq ${#PORTS[]} ] return 0 sleep 2 done return 1 }逻辑说明wait_for_cluster_ready循环里每次都访问第一个容器来探测所有端口而不是分别exec进每个容器这样减少docker exec的上下文切换开销。如果30次循环内约60秒所有节点都没有返回cluster_state:ok脚本返回非0退出码。退出之后建议先看容器日志绝大多数情况是配置文件的appendonly路径没有创建对应目录导致进程直接退出。参数说明健康检查的端口探测用了cluster info而不是ping因为ping只证明进程活着而cluster info能确认集群模块已加载、节点状态正常。这里有一个细节刚启动的节点集群状态可能是fail需要等待它尝试连接其他节点失败后才能进入待命状态这是正常的等循环跑完即可。3.4 创建集群与槽位分配一行命令的事节点全部就绪后剩下的工作就是调用redis-cli --cluster create。这一行命令会自动执行meet、分配主从、迁移槽位三个动作但需要传入正确的节点列表和副本策略。create_cluster() { local node_list for ((i0; iNODE_COUNT; i)); do node_list${IPS[$i]}:${PORTS[$i]} done docker exec redis-node-1 \ redis-cli --cluster create ${node_list} \ --cluster-replicas 1 \ --cluster-yes }逻辑说明--cluster-replicas 1表示每个主节点绑定一个从节点6个节点生成3主3从的拓扑。脚本里把节点列表拼成空格分隔的字符串传输是这里最常用的方式——确保节点列表必须用IP而非容器名因为Redis是通过TCP建立连接它不认docker的内部DNS。--cluster-yes跳过交互确认一键执行的前提。参数说明--cluster-replicas的值可以调成2表示一主双从但节点总数必须能被副本数1整除否则命令会直接报错。脚本可以对这个数量做一次除法校验提前暴露错误比等命令报错更友好。4. 实战跑通在CentOS 7.x上从零部署6节点集群4.1 环境准备docker安装与镜像拉取CentOS 7.x默认自带的docker版本较旧建议先确认docker服务状态再决定是否需要升级。镜像拉取前先确认网络可达性Red Hat系的机器对外部仓库的访问受限比较常见遇到超时换一个镜像源即可。# 检查docker服务状态 systemctl status docker | head -5 # 拉取redis镜像 docker pull redis:7.0-alpine # 创建自定义网络手动指定网段 docker network create --subnet172.30.0.0/16 redis-cluster-net逻辑说明这里特意把网络创建从脚本中拆出来放前面执行是因为网络创建是一个幂等性较差的操作——重复执行同一个名称会报错而脚本设计上要允许反复部署。先建好网络脚本只负责创建和销毁容器这样脚本跑失败后清理容器后重新执行即可不必处理网络冲突。参数说明网段172.30.0.0/16可以用docker network inspect查看是否与其他网络重叠。如果你所在的服务器已经有其他docker网络占用了这个段换成172.31.0.0/16即可。这个参数不需要和公司内部物理网络对齐因为容器网络是隔离的只要和宿主机已有docker网络不冲突即可。4.2 执行一键脚本完整输出解读把前文的三个函数串起来加上变量初始化和最终输出展示就是一个可落地的完整脚本。执行时用bash deploy.sh不要直接./deploy.sh避免忘记赋执行权限。#!/bin/bash # 变量初始化部分上面已定义此处省略 for ((i0; i${NODE_COUNT}; i)); do PORTS($((BASE_PORT i))) IPS(172.30.0.$((10 i))) done echo 开始创建配置... for i in ${!PORTS[]}; do generate_conf $i ${PORTS[$i]} done echo 开始启动容器共 ${NODE_COUNT} 个节点... for i in ${!IPS[]}; do start_container $i ${IPS[$i]} ${PORTS[$i]} done echo 等待节点就绪... if ! wait_for_cluster_ready; then echo 节点未在预期时间内就绪请检查容器状态 exit 1 fi echo 开始创建集群... create_cluster逻辑说明脚本先根据BASE_PORT和NODE_COUNT生成两个平行数组PORTS和IPS所有后续操作都是遍历这两个数组。这种设计避免在函数内部动不动重复计算IP或端口职责分离清晰。执行过程中每个阶段都有提示输出方便在长时间部署时定位卡在哪个环节。参数说明IPS(172.30.0.$((10 i)))这一行把起始IP设为了172.30.0.10留出了前10个地址给以后的额外容器。如果你的宿主机内存紧张可以把NODE_COUNT临时改成6以外的值但注意必须是2的倍数且能被副本数加一整除否则最后一行create_cluster会失败。4.3 执行后的状态验证脚本执行完不要急着认为集群可用了先在宿主机上做三个快速验证端口连通性、节点状态、槽位分配情况。这三个检查能覆盖绝大多数部署问题。# 验证所有数据端口和总线端口都在监听 for p in $(seq 7001 7006); do ss -tlnp | grep -E :${p}|:$((p10000)) | wc -l done # 查看集群节点状态 redis-cli -p 7001 cluster nodes | awk {print $1, $2, $3, $7} # 检查槽位是否分配完整 redis-cli -p 7001 cluster slots | wc -l逻辑说明端口监听检查用ss而不是netstatCentOS 7上ss默认安装且输出更清晰。每个端口输出至少2行数据端口和总线端口各一行如果有端口输出为0说明容器映射失败或进程未启动。cluster slots输出的是分配完成的槽位区间列表正常6节点集群会输出多个区间的组合总数不重要关键是没有返回错误。4.4 redis.conf里必改的6个参数对照容器化部署Redis集群有6个参数几乎每次都要手动调脚本模板里已经改好了但理解背后的原因能帮你快速排查别人写的脚本参数名默认值脚本中的值原因cluster-enablednoyes关闭则Redis以单机模式运行cluster-config-filenodes.confnodes-端口.conf多容器共用默认值会互相覆盖cluster-node-timeout150005000缩短故障转移判定时间appendonlynoyes容器重启后数据可恢复protected-modeyesno开放跨容器访问的必要条件bind127.0.0.10.0.0.0绑定回环地址会阻断跨节点通信参数修正的逻辑cluster-node-timeout默认值是15000毫秒对容器网络来说太长主节点宕机后从节点要等15秒才开始竞选业务侧体现为一段明显的写入超时。降为5000毫秒后故障转移的响应速度更快但要注意这个值设置太小会加重误判风险比如GC停顿超时会频繁触发主从切换。5. 集群落地避坑从翻车现场到稳定运行的5条经验5.1 容器重启后集群瘫痪固定IP与announce-ip的联动关系现象某次服务器重启后所有容器自动恢复运行但业务侧报错集群不可用cluster nodes里全部节点互相标记为fail。原因虽然脚本创建容器时指定了--ip固定地址但Redis集群的nodes.conf文件里记录的是节点首次启动时的IP。重启过程中如果docker网络重建、IP分配被其他容器抢占节点启动后拿着新IP去连接旧IP自然握手失败。解决在generate_conf函数中显式加上cluster-announce-ip值为脚本分配的静态IP。这样即使节点重启后IP变了Redis也会用announce-ip向其他节点宣告自己而非读取网卡的实际地址。5.2 槽位迁移失败手动分配过多的隐性成本现象脚本建集群时人为指定了--cluster-replicas 1然后想扩容把新节点加入集群并迁移部分槽位结果迁移中途频繁超时部分slot显示migrating状态卡住不动。原因当集群的key数量较大生产环境常见百万级别迁移槽位内部执行MIGRATE命令是有超时上限的。脚本自动建集群时槽位为空瞬间完成但后续手动迁移是大key或热点key时单次迁移超过cluster-node-timeout就会被中断。解决扩容动作不要完全手敲命令建议分段执行先reshard少量槽位比如100个观察迁移耗时如果单key迁移超过5秒用redis-cli --cluster reshard配合--cluster-from、--cluster-to参数精细控制必要时在业务低峰期操作。这里的教训是脚本只解决从零建集群解决不了动态扩容场景要做成独立脚本分开管理。5.3 时间不同步引发的选举异常现象集群偶尔出现从节点自动晋升为主节点但主节点并未宕机业务侧出现短暂只读。原因Redis集群的故障转移依赖节点间的PING/PONG心跳和选举超时机制而选举中会对比节点间的cluster-node-timeout和客观下线时间戳。如果宿主机没有配置NTP时间同步多个容器的时间偏差超过几秒从节点可能误判主节点超时提前发起选举。解决在宿主机配置NTP服务同步时间同时在docker run参数里加上--sysctl不是正确解法——正确做法是在宿主机上执行timedatectl set-ntp yesCentOS 7默认可能没开启。容器内的时间由宿主机内核统一维护宿主机同步了容器自然同步。此坑在虚拟化环境下尤其常见母鸡时间漂移会导致所有容器集体中招部署脚本里补一段时间同步检查很有必要。5.4 docker版本过旧导致网络能力缺失现象在CentOS 7.x执行脚本时docker run --ip报错user specified IP address is not supported。原因docker老版本创建自定义网络后需要对应的网络驱动支持静态IP分配。CentOS 7自带的docker 1.13版本对自定义bridge网络的IP指定支持不完整换docker network create --driver bridge也一样。解决升级docker到支持docker network create --subnet的版本或者改用host网络模式。host模式不需要映射端口、不需要指定IP但6个节点的端口都要手动规划且宿主机端口被独占。多数生产服务器会选择升级docker原因在于host模式下容器互相通信都走宿主机回环网卡隔离性差而且容易被其他服务影响端口。5.5 数据目录权限不足导致的隐性启动失败现象容器启动后立即退出docker logs显示Cant open the append-only file: Permission denied。原因/data/redis-cluster/conf目录挂在宿主机上但docker容器内的Redis进程以redis用户运行该用户对宿主机目录没有写权限。CentOS 7的SELinux还会再给一层限制即使chmod 777也可能被SELinux拦截。解决在启动容器前对数据目录执行chcon -Rt container_file_t /data/redis-cluster或直接把宿主机目录chmod -R 777。更稳妥的做法是生成配置目录时就用install -d -m 777避免在脚本中单独依赖后续的手工权限调整。这一个坑非常隐蔽环境上清理过的机器第一次部署大概率会踩中脚本里加上权限初始化代码能少一次排障。6. 压测验证与收尾cluster info之外的三个自检技巧集群建完不测试就等于没做。除了看一眼cluster_state:ok我还会做三个自检全通过后才敢把连接串发给业务方。第一个自检是故障转移演练。用docker stop redis-node-1模拟主节点宕机然后观察从节点的反应时间。正常的集群会在cluster-node-timeout加上选举时间约6-10秒内完成主从切换。如果超过15秒还没恢复写入大概率是心跳参数或网络配置有问题。这个演练值得每次部署后都做一次它能验证从节点的数据完整性也能确认客户端具备重连能力。演练结束后重启停掉的容器它会以从节点身份自动重新加入集群。第二个自检是重启恢复验证。把部署脚本所有容器全部docker stop再全部docker start等待两分钟观察集群是否自动恢复。这里最容易暴露的是announce-ip配置缺失——恢复后节点间会互相报fail。一个健康的集群应当无人工介入地完成恢复它的选举机制和节点发现机制才是真正可靠。第三个自检是写入压测的边界验证。用redis-benchmark压一下集群的写入性能不是为了测QPS而是确认集群的reshard和节点的replicate不会出现瓶颈。使用redis-cli -c集群模式写入一批带hash tag的key观察slot在各个节点间的分布是否均匀。不均匀时调整hash tag的使用方式这比事后加节点更有效——在创建集群时就规划好业务key的分布规则比后期扩缩容的成本低得多。这三个自检做完基本可以从容地把集群交付出去。我的习惯是把部署脚本和自检脚本放在同一个目录每次重建集群后顺手执行一遍。毕竟Redis集群这个技术方向真正考验人的不是建起来而是怎么证明它坏了能自己好。希望这篇笔记能帮你在CentOS 7.x上少走几步弯路把脚本一次跑通把坑留在文档里而不是生产环境。本文还有配套的精品资源点击获取
简介面向需要在 CentOS 7.x 上快速搭建 Redis 集群的运维与开发人员这份资源以 shell 脚本实现了 Docker 环境下的一键部署只需按 README 说明将参数传递给安装脚本即可自动完成镜像加载、节点创建与集群初始化等步骤实测可用。压缩包共含 6 个文件以 sh 脚本为主涵盖部署、卸载与辅助构建三个环节另附 redis.conf 配置模板、redis_docker_images_latest.tar 离线镜像包和 markdown 格式的说明文档整体约 22.46MB。目前已有 1055 人学习下载。通过阅读脚本可理解基于 Docker 的 Redis 集群搭建流程与参数化设计思路也能直接复用或按需调整免去手工逐节点配置的繁琐与排错成本。1. 一键部署Redis集群为什么shell脚本才是CentOS 7上的最优解手动搭建Redis集群是个体力活先把6份redis.conf的端口、总线端口、持久化路径逐项改好再逐个启动容器最后还要敲几十条meet、replicate和addslots命令。任何一步IP写错或端口被占用集群状态就卡在fail排查起来让人头疼。这套流程放在CentOS 7.x上尤其繁琐——旧内核、老版本docker都对网络模式有约束没有脚本兜底很容易翻车。所谓docker一键部署redis集群shell脚本就是把配置生成、容器创建、网络分配、节点握手、主从绑定、槽位分配这六个环节全部收敛到一个可重复执行的脚本里。这一步到位的能力对两类人价值最大一类是需要在测试环境频繁重建集群验证业务逻辑的开发者另一类是生产环境交付前需要快速铺多个独立集群的运维。脚本解决的不只是省时间更重要的是消除人工操作的不确定性——同样的参数跑十次结果必须一致。2. Redis集群的容器化选型固定IP、总线端口与脚本要跨过的三道坎2.1 三种部署方式对比为什么不用docker-compose在CentOS 7.x上把Redis集群容器化常见做法有三种纯docker命令裸跑、docker-compose编排、shell脚本自动化。三者各有边界但针对多个节点组成一个集群这个诉求shell脚本反而是最省心的解。部署方式配置管理粒度固定IP支持故障恢复适用场景纯docker命令单容器需手动指定需人工介入临时验证单节点docker-compose多容器支持但需写死IP需配合外部脚本有固定拓扑的标准化部署shell脚本批量生成与统一操作主动分配并写入配置可内建健康检查多节点集群的反复重建docker-compose适合服务集合的编排比如一个Web应用带一个Redis单节点。但Redis集群是多实例状态内联的拓扑节点之间需要双向发现compose文件里每个服务都要写独立IP、独立端口映射写出来的文件比shell脚本还要啰嗦。而且compose在CentOS 7上的旧版本对自定义网络的支持有差异一旦涉及动态节点数量调整脚本的for循环明显更灵活。2.2 集群创建流程从配置文件生成到槽位分配Redis集群从空壳到可用的完整链路分四步生成配置、启动实例、节点握手、分配槽位。脚本的价值不是替代redis-trib或redis-cli的集群命令而是把前三步重复劳动自动化最后一步用命令一键触发。配置生成阶段每个节点需要独立的port、cluster-config-file、appendonly路径但这些参数除了端口其余高度相似用函数生成模板最合适。启动实例阶段要处理容器数量和网络互通的问题。节点握手阶段Redis 5.0之后可以直接用redis-cli --cluster create自动完成meet和主从分配但前提是节点之间路由可达、端口开放。槽位分配是这个命令内部完成的包含主节点的16384个槽和从节点的replicate绑定。脚本要控制的变量就清楚了每个节点的IP、端口、总线端口端口10000、主从配对方式。其中总线端口最容易被忽略——Redis集群节点间通信用的是port10000的端口容器端口映射漏掉它节点能启动但永远无法完成meet握手。2.3 网络模式与端口映射脚本要解决的三个硬问题CentOS 7.x上给Redis集群容器选网络模式绕不开三个问题容器IP漂移、总线端口暴露、宿主机端口占用。隔离这三个问题就握住了脚本设计的关键。第一个问题是容器IP漂移。默认bridge模式下容器每次重启IP都会变化而Redis集群的nodes.conf里记录的是节点启动时的IP一旦变了集群就认为节点断开。解法是创建自定义bridge网络并手动指定静态IP脚本里用docker run --ip显式分配。第二个问题是总线端口。即使容器IP固定如果宿主机访问不到端口映射后的总线端口节点之间还是会握手失败。端口映射要同时覆盖数据端口和总线端口两个端口总共6个节点就要映射12个端口脚本里用同一份端口列表循环生成映射参数最稳妥。第三个问题是端口占用的冲突排查。生产环境里6000-6010和16000-16010这两段经常被其他中间件占用脚本最好支持从外部传入起始端口而不是硬编码这样遇到冲突时改一行启动参数就能换一段干净端口。3. 编写一键部署脚本从配置模板到cluster create3.1 脚本骨架变量定义与配置生成函数写脚本前先把变量拆成使用者可调和脚本内部使用两组。使用者可调的部分是节点数量、起始端口、Redis镜像版本、网络网段内部使用的部分是IP列表、端口列表、配置文件名。这样设计的好处是将来调整集群规模时不需要改动逻辑代码。#!/bin/bash # 可调参数区域 REDIS_IMAGEredis:7.0-alpine # 镜像按需更换测试环境用alpine版启动更快 BASE_PORT7001 # 起始数据端口总线端口自动10000 NODE_COUNT6 # 节点总数生产建议至少6个 NET_NAMEredis-cluster-net # 自定义网络名 NET_SUBNET172.30.0.0/16 # 网段避免与公司现有网段冲突 START_IP172.30.0.10 # 容器起始IP配合递增逻辑分配 # 内部变量区域 PORTS() IPS() TOTAL0逻辑说明镜像用alpine版本主要是为了减少拉取时间和容器体积实测同一台机器跑6个alpine容器比debian版的Redis容器少占约600MB内存。网段必须手动指定不能依赖docker自动分配的默认段否则宿主机已有的容器网络可能冲突。注意NODE_COUNT设定为6是最小集群配置3主3从少于6个脚本应直接退出提示防止建立一个没有故障转移能力的假集群。参数说明START_IP决定了容器IP的起点脚本后续按顺序递增。如果你在开发环境已经有别的容器占了这个网段把这个起始IP往后挪即可。Redis版本建议选带cluster支持的稳定版太老的版本对总线的处理方式不同脚本里--cluster create的参数兼容性会有差异。3.2 配置文件生成用一份模板渲染出多份conf配置生成这一步的要点是统一基础配置差异化端口类参数。不要为每个节点手写完整conf而是通过cat模板配合变量替换一次性生成。下面代码把公共参数和差异参数分开处理避免漏改。generate_conf() { local idx$1 local port$2 local dir/data/redis-cluster/conf/redis-${port}.conf mkdir -p $(dirname $dir) cat $dir EOF port ${port} cluster-enabled yes cluster-config-file nodes-${port}.conf cluster-node-timeout 5000 appendonly yes daemonize no protected-mode no bind 0.0.0.0 EOF }逻辑说明配置文件里的bind 0.0.0.0是关键——容器内的Redis默认只绑定本地回环地址如果这里不放开跨容器的节点握手必然失败。cluster-config-file为每个节点独立命名避免多个容器共享同一个data目录时互相覆盖文件。cluster-node-timeout设为5000毫秒是经验值设太短网络抖动就会被误判为主节点下线触发不必要的故障迁移。参数说明这段模板中没有指定cluster-announce-ip这是有意为之——在自定义bridge网络里手动指定了容器IP且没有做NAT映射Redis可以自动识别自己的IP。如果后续改成端口映射模式比如容器在远程宿主机就必须在模板里追加cluster-announce-ip为宿主机IP这一点会在避坑章节详解。3.3 启动容器与健康检查等待就绪而非盲目sleep启动容器不能一把梭直接建集群必须等所有节点进入集群待命状态。常见做法是循环执行redis-cli -p PORT cluster info从返回结果里判断cluster_state不再是fail后才继续。sleep固定秒数也算方案但对老机器不友好——配置生成慢、容器启动慢很容易在还没就绪时就执行建集群命令。start_container() { local idx$1 local ip$2 local port$3 docker run -d \ --name redis-node-${idx} \ --network ${NET_NAME} \ --ip ${ip} \ -p ${port}:${port} -p $((port10000)):$((port10000)) \ -v /data/redis-cluster/conf/redis-${port}.conf:/usr/local/etc/redis/redis.conf \ ${REDIS_IMAGE} \ redis-server /usr/local/etc/redis/redis.conf } wait_for_cluster_ready() { local ready0 for _ in $(seq 1 30); do ready0 for port in ${PORTS[]}; do info$(docker exec redis-node-1 redis-cli -p ${port} cluster info 2/dev/null) if echo $info | grep -q cluster_state:ok; then ready$((ready1)) fi done [ $ready -eq ${#PORTS[]} ] return 0 sleep 2 done return 1 }逻辑说明wait_for_cluster_ready循环里每次都访问第一个容器来探测所有端口而不是分别exec进每个容器这样减少docker exec的上下文切换开销。如果30次循环内约60秒所有节点都没有返回cluster_state:ok脚本返回非0退出码。退出之后建议先看容器日志绝大多数情况是配置文件的appendonly路径没有创建对应目录导致进程直接退出。参数说明健康检查的端口探测用了cluster info而不是ping因为ping只证明进程活着而cluster info能确认集群模块已加载、节点状态正常。这里有一个细节刚启动的节点集群状态可能是fail需要等待它尝试连接其他节点失败后才能进入待命状态这是正常的等循环跑完即可。3.4 创建集群与槽位分配一行命令的事节点全部就绪后剩下的工作就是调用redis-cli --cluster create。这一行命令会自动执行meet、分配主从、迁移槽位三个动作但需要传入正确的节点列表和副本策略。create_cluster() { local node_list for ((i0; iNODE_COUNT; i)); do node_list${IPS[$i]}:${PORTS[$i]} done docker exec redis-node-1 \ redis-cli --cluster create ${node_list} \ --cluster-replicas 1 \ --cluster-yes }逻辑说明--cluster-replicas 1表示每个主节点绑定一个从节点6个节点生成3主3从的拓扑。脚本里把节点列表拼成空格分隔的字符串传输是这里最常用的方式——确保节点列表必须用IP而非容器名因为Redis是通过TCP建立连接它不认docker的内部DNS。--cluster-yes跳过交互确认一键执行的前提。参数说明--cluster-replicas的值可以调成2表示一主双从但节点总数必须能被副本数1整除否则命令会直接报错。脚本可以对这个数量做一次除法校验提前暴露错误比等命令报错更友好。4. 实战跑通在CentOS 7.x上从零部署6节点集群4.1 环境准备docker安装与镜像拉取CentOS 7.x默认自带的docker版本较旧建议先确认docker服务状态再决定是否需要升级。镜像拉取前先确认网络可达性Red Hat系的机器对外部仓库的访问受限比较常见遇到超时换一个镜像源即可。# 检查docker服务状态 systemctl status docker | head -5 # 拉取redis镜像 docker pull redis:7.0-alpine # 创建自定义网络手动指定网段 docker network create --subnet172.30.0.0/16 redis-cluster-net逻辑说明这里特意把网络创建从脚本中拆出来放前面执行是因为网络创建是一个幂等性较差的操作——重复执行同一个名称会报错而脚本设计上要允许反复部署。先建好网络脚本只负责创建和销毁容器这样脚本跑失败后清理容器后重新执行即可不必处理网络冲突。参数说明网段172.30.0.0/16可以用docker network inspect查看是否与其他网络重叠。如果你所在的服务器已经有其他docker网络占用了这个段换成172.31.0.0/16即可。这个参数不需要和公司内部物理网络对齐因为容器网络是隔离的只要和宿主机已有docker网络不冲突即可。4.2 执行一键脚本完整输出解读把前文的三个函数串起来加上变量初始化和最终输出展示就是一个可落地的完整脚本。执行时用bash deploy.sh不要直接./deploy.sh避免忘记赋执行权限。#!/bin/bash # 变量初始化部分上面已定义此处省略 for ((i0; i${NODE_COUNT}; i)); do PORTS($((BASE_PORT i))) IPS(172.30.0.$((10 i))) done echo 开始创建配置... for i in ${!PORTS[]}; do generate_conf $i ${PORTS[$i]} done echo 开始启动容器共 ${NODE_COUNT} 个节点... for i in ${!IPS[]}; do start_container $i ${IPS[$i]} ${PORTS[$i]} done echo 等待节点就绪... if ! wait_for_cluster_ready; then echo 节点未在预期时间内就绪请检查容器状态 exit 1 fi echo 开始创建集群... create_cluster逻辑说明脚本先根据BASE_PORT和NODE_COUNT生成两个平行数组PORTS和IPS所有后续操作都是遍历这两个数组。这种设计避免在函数内部动不动重复计算IP或端口职责分离清晰。执行过程中每个阶段都有提示输出方便在长时间部署时定位卡在哪个环节。参数说明IPS(172.30.0.$((10 i)))这一行把起始IP设为了172.30.0.10留出了前10个地址给以后的额外容器。如果你的宿主机内存紧张可以把NODE_COUNT临时改成6以外的值但注意必须是2的倍数且能被副本数加一整除否则最后一行create_cluster会失败。4.3 执行后的状态验证脚本执行完不要急着认为集群可用了先在宿主机上做三个快速验证端口连通性、节点状态、槽位分配情况。这三个检查能覆盖绝大多数部署问题。# 验证所有数据端口和总线端口都在监听 for p in $(seq 7001 7006); do ss -tlnp | grep -E :${p}|:$((p10000)) | wc -l done # 查看集群节点状态 redis-cli -p 7001 cluster nodes | awk {print $1, $2, $3, $7} # 检查槽位是否分配完整 redis-cli -p 7001 cluster slots | wc -l逻辑说明端口监听检查用ss而不是netstatCentOS 7上ss默认安装且输出更清晰。每个端口输出至少2行数据端口和总线端口各一行如果有端口输出为0说明容器映射失败或进程未启动。cluster slots输出的是分配完成的槽位区间列表正常6节点集群会输出多个区间的组合总数不重要关键是没有返回错误。4.4 redis.conf里必改的6个参数对照容器化部署Redis集群有6个参数几乎每次都要手动调脚本模板里已经改好了但理解背后的原因能帮你快速排查别人写的脚本参数名默认值脚本中的值原因cluster-enablednoyes关闭则Redis以单机模式运行cluster-config-filenodes.confnodes-端口.conf多容器共用默认值会互相覆盖cluster-node-timeout150005000缩短故障转移判定时间appendonlynoyes容器重启后数据可恢复protected-modeyesno开放跨容器访问的必要条件bind127.0.0.10.0.0.0绑定回环地址会阻断跨节点通信参数修正的逻辑cluster-node-timeout默认值是15000毫秒对容器网络来说太长主节点宕机后从节点要等15秒才开始竞选业务侧体现为一段明显的写入超时。降为5000毫秒后故障转移的响应速度更快但要注意这个值设置太小会加重误判风险比如GC停顿超时会频繁触发主从切换。5. 集群落地避坑从翻车现场到稳定运行的5条经验5.1 容器重启后集群瘫痪固定IP与announce-ip的联动关系现象某次服务器重启后所有容器自动恢复运行但业务侧报错集群不可用cluster nodes里全部节点互相标记为fail。原因虽然脚本创建容器时指定了--ip固定地址但Redis集群的nodes.conf文件里记录的是节点首次启动时的IP。重启过程中如果docker网络重建、IP分配被其他容器抢占节点启动后拿着新IP去连接旧IP自然握手失败。解决在generate_conf函数中显式加上cluster-announce-ip值为脚本分配的静态IP。这样即使节点重启后IP变了Redis也会用announce-ip向其他节点宣告自己而非读取网卡的实际地址。5.2 槽位迁移失败手动分配过多的隐性成本现象脚本建集群时人为指定了--cluster-replicas 1然后想扩容把新节点加入集群并迁移部分槽位结果迁移中途频繁超时部分slot显示migrating状态卡住不动。原因当集群的key数量较大生产环境常见百万级别迁移槽位内部执行MIGRATE命令是有超时上限的。脚本自动建集群时槽位为空瞬间完成但后续手动迁移是大key或热点key时单次迁移超过cluster-node-timeout就会被中断。解决扩容动作不要完全手敲命令建议分段执行先reshard少量槽位比如100个观察迁移耗时如果单key迁移超过5秒用redis-cli --cluster reshard配合--cluster-from、--cluster-to参数精细控制必要时在业务低峰期操作。这里的教训是脚本只解决从零建集群解决不了动态扩容场景要做成独立脚本分开管理。5.3 时间不同步引发的选举异常现象集群偶尔出现从节点自动晋升为主节点但主节点并未宕机业务侧出现短暂只读。原因Redis集群的故障转移依赖节点间的PING/PONG心跳和选举超时机制而选举中会对比节点间的cluster-node-timeout和客观下线时间戳。如果宿主机没有配置NTP时间同步多个容器的时间偏差超过几秒从节点可能误判主节点超时提前发起选举。解决在宿主机配置NTP服务同步时间同时在docker run参数里加上--sysctl不是正确解法——正确做法是在宿主机上执行timedatectl set-ntp yesCentOS 7默认可能没开启。容器内的时间由宿主机内核统一维护宿主机同步了容器自然同步。此坑在虚拟化环境下尤其常见母鸡时间漂移会导致所有容器集体中招部署脚本里补一段时间同步检查很有必要。5.4 docker版本过旧导致网络能力缺失现象在CentOS 7.x执行脚本时docker run --ip报错user specified IP address is not supported。原因docker老版本创建自定义网络后需要对应的网络驱动支持静态IP分配。CentOS 7自带的docker 1.13版本对自定义bridge网络的IP指定支持不完整换docker network create --driver bridge也一样。解决升级docker到支持docker network create --subnet的版本或者改用host网络模式。host模式不需要映射端口、不需要指定IP但6个节点的端口都要手动规划且宿主机端口被独占。多数生产服务器会选择升级docker原因在于host模式下容器互相通信都走宿主机回环网卡隔离性差而且容易被其他服务影响端口。5.5 数据目录权限不足导致的隐性启动失败现象容器启动后立即退出docker logs显示Cant open the append-only file: Permission denied。原因/data/redis-cluster/conf目录挂在宿主机上但docker容器内的Redis进程以redis用户运行该用户对宿主机目录没有写权限。CentOS 7的SELinux还会再给一层限制即使chmod 777也可能被SELinux拦截。解决在启动容器前对数据目录执行chcon -Rt container_file_t /data/redis-cluster或直接把宿主机目录chmod -R 777。更稳妥的做法是生成配置目录时就用install -d -m 777避免在脚本中单独依赖后续的手工权限调整。这一个坑非常隐蔽环境上清理过的机器第一次部署大概率会踩中脚本里加上权限初始化代码能少一次排障。6. 压测验证与收尾cluster info之外的三个自检技巧集群建完不测试就等于没做。除了看一眼cluster_state:ok我还会做三个自检全通过后才敢把连接串发给业务方。第一个自检是故障转移演练。用docker stop redis-node-1模拟主节点宕机然后观察从节点的反应时间。正常的集群会在cluster-node-timeout加上选举时间约6-10秒内完成主从切换。如果超过15秒还没恢复写入大概率是心跳参数或网络配置有问题。这个演练值得每次部署后都做一次它能验证从节点的数据完整性也能确认客户端具备重连能力。演练结束后重启停掉的容器它会以从节点身份自动重新加入集群。第二个自检是重启恢复验证。把部署脚本所有容器全部docker stop再全部docker start等待两分钟观察集群是否自动恢复。这里最容易暴露的是announce-ip配置缺失——恢复后节点间会互相报fail。一个健康的集群应当无人工介入地完成恢复它的选举机制和节点发现机制才是真正可靠。第三个自检是写入压测的边界验证。用redis-benchmark压一下集群的写入性能不是为了测QPS而是确认集群的reshard和节点的replicate不会出现瓶颈。使用redis-cli -c集群模式写入一批带hash tag的key观察slot在各个节点间的分布是否均匀。不均匀时调整hash tag的使用方式这比事后加节点更有效——在创建集群时就规划好业务key的分布规则比后期扩缩容的成本低得多。这三个自检做完基本可以从容地把集群交付出去。我的习惯是把部署脚本和自检脚本放在同一个目录每次重建集群后顺手执行一遍。毕竟Redis集群这个技术方向真正考验人的不是建起来而是怎么证明它坏了能自己好。希望这篇笔记能帮你在CentOS 7.x上少走几步弯路把脚本一次跑通把坑留在文档里而不是生产环境。本文还有配套的精品资源点击获取
