当前位置：首页 > article >正文

Redis7——基础篇（六）

article 2026/4/9 20:09:09

前言：此篇文章系本人学习过程中记录下来的笔记，里面难免会有不少欠缺的地方，诚心期待大家多多给予指教。

基础篇：

Redis（一）
Redis（二）
Redis（三）
Redis（四）
Redis（五）

接上期内容：上期完成了Redis主从模式的学习。下面开始学习Redis的哨兵模式(重点)，话不多说，直接发车。

一、定义

Q：既然已经有了主从模式，为什么还要推出哨兵模式呢？

A：在主从模式的架构里，当 Master 节点发生宕机故障时，从节点并不会自动晋升为新的Master。要是 Master 节点在短时间内无法恢复正常运行，系统就会陷入一个棘手的状况。此时，系统仅仅保留了读操作的功能，却丧失了写操作的能力。这种读写能力的失衡，显然无法满足实际业务对系统高可用性和数据完整性的要求。

而哨兵模式正是为了解决上述主从模式的痛点而诞生。它通过一组Sentinel节点来监控主从架构中的Redis实例，当主节点出现故障时，自动将一个从节点晋升为主节点，并让其他从节点重新指向新的主节点，从而实现自动故障转移，保证系统的高可用性。俗称：无人值守运维。

二、功能

主从监控：哨兵节点不断地检查主节点和从节点是否正常运行，通过定期发送 PING 命令来判断节点的健康状态。
消息通知：当某个 Redis 实例出现问题时，哨兵可以通过 API 向管理员或其他应用程序发送通知，以便及时处理。
自动故障转移：这是哨兵模式的核心功能。当主节点不可用时，哨兵会在从节点中选举一个新的主节点，并调整其他从节点的配置，使其指向新的主节点。
配置中心：客户端可以通过连接哨兵来获取主节点信息。

三、实操

（一）、架构说明

3个哨兵，1个Master，2个Slave。哨兵自动监控和维护集群，不存放数据，只是吹哨人，Master负责存，Slave负责读。

由于机器硬件问题，同时启动6台虚拟机，电脑吃不消，所以将哨兵的集群放在6379上。

（二）、实操步骤

1、拷贝原生配置

拷贝redis压缩目录下的sentinel.conf到/myredis下。

2、修改参数配置

2.1、参数说明

常用参数：

bind：服务监听地址，用于客户端连接，默认本机

daemonize：是否以后台daemon方式运行

protected-mode：安全保护模式
port：端口
logfile：日志文件路径
pidfilepid：文件路径
dir：工作目录

sentinel monitor <master-name> <ip> <redis-port> <quorum>：设置要监控的master服务器，quorum代表确认客观下线的最少的哨兵数量

sentinel auth-pass <master-name> <password>：连接Master的密码

其他参数：

sentinel down-after-milliseconds <master-name> <milliseconds>：指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

sentinel parallel-syncs <master-name> <nums>：表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据

sentinel failover-timeout <master-name> <milliseconds>：故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

sentinel notification-script <master-name> <script-path> ：配置当某一事件发生时所需要执行的脚本

sentinel client-reconfig-script <master-name> <script-path>：客户端重新配置主节点参数脚本

2.2、修改配置

由于sentinel集群是在6379上，所以需要配置3份sentinel.conf文件。

vim 打开sentinel26379.conf 文件，删除里面所有内容，拷贝下面内容（改为自己虚拟机的IP地址）：

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile /myredis/logs/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.112.129 6379 2
sentinel auth-pass mymaster root

23680、23681也一样，但是只要改端口号即可（改为自己虚拟机的IP地址）：

3、测试主从模式

如果不知道，主从模式怎么搭建，请前往Redis（五）

启动Master，两台slave，并查看主从关系。

Master：

启动80、81slave：

确定主从关系：

测试主从是否正常工作：

4、配置哨兵集群

在6379那台机器上启动sentinel集群。

哨兵集群已成功启动。

5、模拟故障场景

我们自己手动关闭6379服务器，模拟master挂了。

5.1、思考问题

Q1：Master主机挂了，两台从机是否正常？

A：从机数据正常。

Q2：是否从两台slave中选出新的Master？

A：会。如Q1所示，6380和6381在Master宕机后，哨兵会进行选举和故障转移，导致从机在获取数据时，出现Server closed或者broken pipe错误，但是会立马恢复了。

此时6380已经成为了new Master，6381也变成了6380的slave。

Q3：之前的Master恢复后，谁会是新的Master？双Master会不会冲突？

A：新Master当然是哨兵选举出来的（本次是6380，下次不知道是谁），不会出现双Master的场景，以前的Master重新恢复后，会变成new Master的slave。

启动6379，查看主从关系：

查看Master6380：

完美收官。

6、对比配置文件

后续又重新玩了一遍，所以新Master由6380变成了6381。

查看sentinel26379.conf文件。

老Master6379.conf：

new Master 6381.conf：

结论：文件的内容，在运行期间会被sentinel动态进行更改。

当Master宕机后，哨兵选举出new Master之后，sentinel会对oldMaster_redis.conf、slave_redis.conf、sentinel.conf文件的内容进行更改，即oldMaster_redis.conf中会多一行slaveof的配置，newMaster_redis.conf中会移除之前的配置，而三个sentinel.conf的监控目标也会随之调换。

四、哨兵模式运行流程和选举流程

（一）、主观下线

所谓主观下线（Subjectively Down，简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，或者二者之间的网络不通等等原因）。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息，那么这个Sentinel会主观的(单方面的)认为这个master不可以用了。

sentinel.conf文件中：

sentinel down-after-milliseconds <master-name> <milliseconds>

表示Master被当前sentinel实例认定为失效的间隔时间，这个配置其实就是进行主观下线的一个依据，Master在多长时间内一直没有给sentinel返回有效信息，则认定该Master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。

（二）、客观下线

当一个Sentinel节点将主节点标记为 “主观下线” 后，它会通过Sentinel之间的gossip协议（流言协议）将这个信息传播给其他 Sentinel 节点。当有足够数量（quorum）的Sentinel节点都认为主节点处于 “主观下线” 状态时，这个主节点就会被标记为 “客观下线”（Objectively Down）。

quorum这个参数是进行客观下线的一个依据

意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

sentinel.conf文件中：

（三）、选举leader

当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）也即被选举出的兵王进行failover（故障迁移）。

Q：领导者哨兵节点如何选举出来的？

A：监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得，即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。这里涉及到一个算法问题，不做过多阐述，有兴趣可以私底下学习。

（四）、故障转移

故障转移分为三个步骤。可以趣称为“新主登基”、“群臣俯首”、“旧主拜服”。

（一）、“新主登基”

新主登基指：某个slave节点被选为Master。

从slave节点中选出new Master的规则：优先级-->偏移量-->Run ID

1、优先级

redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高 )，默认100。

2、偏移量

指复制偏移位置offset最大的从节点，通俗一点就是谁从原Master哪儿复制的key多，谁就当新的Master。

3、Run ID

Run ID是Redis 实例启动时生成的一个随机的 40 位十六进制字符串，全局唯一。哨兵会选择 Run ID字典序最小的从节点作为新的主节点

4、选举流程图

（二）、“群臣俯首”

群臣俯首指：当new Master选举出来后，剩余的slave节点脱离宕机的Master，重新连接的新的Master（可以从sentinel.log文件查看)。具体分为二步：

1、Sentinel leader会对选举出的new Master执行slaveof no one操作，将其提升为Master节点。

2、Sentinel leader向其它slave发送命令，让剩余的slave成为新的Master节点的slave。

（三）、“旧主拜服”

旧主拜服指：已经宕机的Master故障恢复，重启成功了，从新加入。但是身份由以前的Master变成slave。

（四）、故障转移小总结

上述的failover操作均由sentinel自己独自完成，完全无需人工干预。

五、使用注意事项

哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用。
哨兵节点的数量应该是奇数。
各个哨兵节点的配置应一致。
如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射。
哨兵集群+主从复制，并不能保证数据零丢失。

六、总结

Redis哨兵模式通过监控、通知和自动故障转移机制，为 Redis集群提供了高可用性保障。合理配置和应用 Redis哨兵模式，可以有效地提升系统的稳定性和性能。在实际应用中，需要根据具体的业务需求和场景，灵活调整配置参数，以充分发挥 Redis 哨兵模式的优势。

ps：努力到底，让持续学习成为贯穿一生的坚守。学习笔记持续更新中。。。。