【愚公系列】2023年06月 Java教学课程 128-Redis的哨兵模式

一、哨兵模式

1.哨兵简介

1.1 哨兵概念

首先我们来看一个业务场景：如果redis的master宕机了，此时应该怎么办？

那此时我们可能需要从一堆的slave中重新选举出一个新的master，那这个操作过程是什么样的呢？这里面会有什么问题出现呢？

要实现这些功能，我们就需要redis的哨兵，那哨兵是什么呢？

哨兵

哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。

1.2 哨兵作用

哨兵的作用：

• 监控：监控master和slave

不断的检查master和slave是否正常运行

master存活检测、master与slave运行情况检测

• 通知（提醒）：当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知

• 自动故障转移：断开master与slave连接，选取一个slave作为master，将其他slave连接新的master，并告知客户端新的服务器地址

注意：哨兵也是一台redis服务器，只是不提供数据相关服务，通常哨兵的数量配置为单数

2.启用哨兵

配置哨兵

• 配置一拖二的主从结构（利用之前的方式启动即可）

• 配置三个哨兵（配置相同，端口不同），参看sentinel.conf

1：设置哨兵监听的主服务器信息， sentinel_number表示参与投票的哨兵数量

sentinel monitor master_name master_host master_port sentinel_number

2：设置判定服务器宕机时长，该设置控制是否进行主从切换

sentinel down-after-milliseconds master_name million_seconds

3：设置故障切换的最大超时时

sentinel failover-timeout master_name million_seconds

4：设置主从切换后，同时进行数据同步的slave数量，数值越大，要求网络资源越高，数值越小，同步时间越长

sentinel parallel-syncs master_name sync_slave_number

• 启动哨兵

redis-sentinel filename

3.哨兵工作原理

哨兵在进行主从切换过程中经历三个阶段

• 监控

• 通知

• 故障转移

3.1 监控

用于同步各个节点的状态信息

![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UeKUfxmb-1680315547457)(./img/19.png)]](https://img-blog.csdnimg.cn/a5a524be38934cb681d4e8812d81c334.png )

• 获取各个sentinel的状态（是否在线）

• 获取master的状态

master属性
prunid
prole：master
各个slave的详细信息

• 获取所有slave的状态（根据master中的slave信息）

slave属性
prunid
prole：slave
pmaster_host、master_port
poffset

其内部的工作原理具体如下：

![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-58yv9SG4-1680315547458)(./img/20.png)]](https://img-blog.csdnimg.cn/eb6812c9ad0e46acb25e3d719e977217.png )

3.2 通知

sentinel在通知阶段要不断的去获取master/slave的信息，然后在各个sentinel之间进行共享，具体的流程如下：

![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PlmXuTvN-1680315547458)(./img/21.png)]](https://img-blog.csdnimg.cn/146bcc3904a24f4b9fbfb0b4de44903e.png )

3.3 故障转移

当master宕机后sentinel是如何知晓并判断出master是真的宕机了呢？我们来看具体的操作流程

![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qAv5cKMg-1680315547458)(./img/22.png)]](https://img-blog.csdnimg.cn/bd0c628a9d164d4d8fef4863221ac3c1.png )

当sentinel认定master下线之后，此时需要决定更换master，那这件事由哪个sentinel来做呢？这时候sentinel之间要进行选举，如下图所示：

![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GoofOA6c-1680315547459)(./img/23.png)]](https://img-blog.csdnimg.cn/17a66265fe17404e9af807faec6f2989.png )

在选举的时候每一个人手里都有一票，而每一个人的又都想当这个处理事故的人，那怎么办？大家就开始抢，于是每个人都会发出一个指令，在内网里边告诉大家我要当选举人，比如说现在的sentinel1和sentinel4发出这个选举指令了，那么sentinel2既能接到sentinel1的也能接到sentinel4的，接到了他们的申请以后呢，sentinel2他就会把他的一票投给其中一方，投给谁呢？谁先过来我投给谁，假设sentinel1先过来，所以这个票就给到了sentinel1。那么给过去以后呢，现在sentinel1就拿到了一票，按照这样的一种形式，最终会有一个选举结果。对应的选举最终得票多的，那自然就成为了处理事故的人。需要注意在这个过程中有可能会存在失败的现象，就是一轮选举完没有选取，那就会接着进行第二轮第三轮直到完成选举。

接下来就是由选举胜出的sentinel去从slave中选一个新的master出来的工作，这个流程是什么样的呢？

首先它有一个在服务器列表中挑选备选master的原则

• 不在线的OUT

• 响应慢的OUT

• 与原master断开时间久的OUT

• 优先原则

优先级
offset
runid

选出新的master之后，发送指令（ sentinel ）给其他的slave：

• 向新的master发送slaveof no one

• 向其他slave发送slaveof 新masterIP端口

总结：故障转移阶段

1. 发现问题，主观下线与客观下线

2. 竞选负责人

3. 优选新master

4. 新master上任，其他slave切换master，原master作为slave故障恢复后连接