告别手动运维!手把手教你搭建Redis哨兵高可用集群

张开发
2026/6/8 4:29:02 15 分钟阅读
告别手动运维!手把手教你搭建Redis哨兵高可用集群
前言这是在linux上做的不要傻傻的在windows上敲。在上一篇文章中我们深入探讨了Redis主从同步的原理。但是单纯的主从架构有一个致命弱点当Master节点宕机时整个集群将失去写能力必须依靠人工手动介入将某个Slave提升为Master。这不仅效率低下在深夜更是运维人员的噩梦。为了解决这个问题Redis引入了哨兵Sentinel机制。它就像是Redis集群的“自动导航系统”能够实时监控健康状态并在危急时刻自动完成故障转移。今天我们就通过实战手把手教你如何搭建一个由3个哨兵节点组成的高可用集群。哨兵集群架构设计为了实现高可用哨兵本身也必须以集群形式存在避免单点故障。我们今天的实验环境如下监控对象之前搭建好的Redis主从集群1个Master:70012个Slaves。哨兵集群由3个Sentinel节点组成分别运行在不同端口。实例名称IP地址端口工作目录Sentinel 1192.168.80.13427001/tmp/s1Sentinel 2192.168.80.13427002/tmp/s2Sentinel 3192.168.80.13427003/tmp/s3配置文件详解与批量处理首先我们需要在/tmp目录下创建s1、s2、s3三个工作目录并编写配置文件。核心配置以s1为例在s1目录下创建sentinel.conf填入以下关键配置port 27001 # 声明当前哨兵的IP如果是多网卡环境建议配置 sentinel announce-ip 192.168.80.134 # 核心配置监控主节点 # 格式sentinel monitor 主节点名称 IP 端口 quorum sentinel monitor mymaster 192.168.80.134 7001 2 # 指定工作目录 dir /tmp/s1这里有一个关键参数quorum配置为2它代表“法定人数”。只有当至少2个哨兵超过总数3的一半都认为Master挂了才会真正触发故障转移客观下线。批量处理技巧为了效率我们可以先写好s1的配置然后复制并批量修改# 1. 复制配置文件 echo s2 s3 | xargs -t -n 1 cp s1/sentinel.conf # 2. 批量修改端口和目录使用sed命令 sed -i -e s/27001/27002/g -e s/s1/s2/g s2/sentinel.conf sed -i -e s/27001/27003/g -e s/s1/s3/g s3/sentinel.conf启动与故障转移实战分别在三个终端窗口启动哨兵redis-sentinel s1/sentinel.conf redis-sentinel s2/sentinel.conf redis-sentinel s3/sentinel.conf启动后哨兵会自动发现彼此并组成集群。此时如果你手动杀掉Master进程你会在日志中看到一场精彩的“自动救援”sdown某个哨兵首先发现Master无响应标记为“主观下线”。odown超过quorum数量的哨兵达成共识标记为“客观下线”。vote-for-leader哨兵们通过Raft算法选举出一个Leader来执行故障转移。selected-slaveLeader根据优先级、Offset等规则选出一个数据最新的Slave。promoted-slave向选中的Slave发送SLAVEOF NO ONE将其提升为新Master。switch-master通知所有其他节点和新旧Master建立连接集群恢复服务。原主节点的“复活”最神奇的一幕发生在原Master重启后。当它重新启动并加入集群时哨兵会自动识别它并将其配置为新Master的Slave。这意味着原本的主节点在恢复后会自动降级默默地在后台同步数据确保集群的高可用性不受影响。知识小结知识点核心内容考试重点/易混淆点难度系数哨兵集群搭建创建三个哨兵实例目录(s1/s2/s3)配置不同端口(27001/27002/27003)配置文件关键参数端口、IP声明、监控主节点、quorum值⭐⭐哨兵配置文件包含端口、监控主节点(7001)、quorum值(2)、工作目录等配置项quorum值设置逻辑哨兵数量过半(3台哨兵配2)⭐⭐⭐哨兵监控机制通过监控主节点获取整个集群信息(info replication命令)看似只监控master实际监控整个集群⭐⭐故障恢复流程1. 主观下线(SDOWN)→客观下线(ODOWN)2. 哨兵选举leader3. 从节点升主(slaveof no one)客观下线判定条件超过quorum数量的哨兵认为故障⭐⭐⭐⭐主从切换过程1. 新主节点执行slaveof no one2. 向其他节点广播新主信息3. 原主恢复后自动成为从节点关键命令序列slaveof→reconfig→replica同步⭐⭐⭐⭐哨兵集群特性自动完成状态监测和故障恢复无需人工干预配置核心是监控主节点信息和quorum值⭐⭐通过今天的实战我们成功为Redis集群装上了“自动导航”。但别忘了哨兵虽然强大配置不当也可能引发“脑裂”问题。在下一篇文章中我们将探讨哨兵模式的潜在风险与生产环境优化建议。

更多文章