Redis7——基础篇（六）

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

基础篇：

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文件中：