redis7基础篇2 redis的哨兵模式2

目录

一 哨兵模式

1.1 redis的哨兵模式作用

1.2 redis的哨兵模式架构

1.3 redis的哨兵模式参数说明

二  redis的哨兵模式搭建

2.1 redis的主从复制模式

2.2 redis的sentinel配置文件

2.3 redis的实例节点和sentinel节点启动

3.3 redis的哨兵模式原理

3.3.1 redis的哨兵模式操作原理

3.4 redis的哨兵模式优缺点

---

一 哨兵模式

1.1 redis的哨兵模式作用

1.主从监控：监控主从redis库运行是否正常

2.消息通知：哨兵可以将故障转移的结果发送给客户端

3.故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新的master

4.配置中心：客户端通过连接哨兵来获得当前redis服务的主节点地址。

1.2 redis的哨兵模式架构

3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人。

1主2从：用于数据读取和存放。

1.3 redis的哨兵模式参数说明

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

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

Protected-mode： 安全保护模式

Port： 端口

Logfile： 日志文件路径

Pidfile： pid文件路径

Dir：工作目录

Sentinel monitor 《master-name》《ip》 《redis-port》《quorum》 设置要监控master服务器。Quorum 表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。

Sentinel auth-pass 《master-name》 《password》：master设置了密码，连接master服务的密码。

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

指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线。

Sentinel parallel -syncs 《master-name》《nums》

表示允许并行同步的slave个数，当master挂了后，哨兵会选出新的master，此时，剩余的slave会向新的mster发起同步数据。

Sentinel failvoer-timeout 《master-name》<milliseconds>

故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败。

Sentinel notification-script 《master-name》《script-path》

配置当某一事件发生时所需要执行的脚本。

Setinle client-reconfig-script 《master-name》《script-path》

二  redis的哨兵模式搭建

2.1 redis的主从复制模式

先搭建好主从复制模式

 在6379配置文件中：6379后续可能会变成从机，需要设置访问新主机的密码，请设置masterauth项访问密码为111111，不然后续可能报错master_link_status:down

在6380配置文件中：设置校验密码和隶属主master的ip

在6381配置文件中：设置校验密码和隶属主master的ip

2.2 redis的sentinel配置文件

由于机器硬件关系，我们的3个哨兵都同时配置进192.168.111.169的同一台机器。

 

配置文件sentinel26379.conf内容：

配置文件sentinel26380.conf内容：

配置文件sentinel26381.conf内容：

2.3 redis的实例节点和sentinel节点启动

1.三台实例的主从启动

 2.启动3个哨兵，并查看主从关系

2.根据哨兵原理，本案例选举6381，为新的master节点

3.重启6379，可以看到原来的master变为了slave

4.登录6381服务，查询已有两个slave节点 

3.3 redis的哨兵模式原理

当一个主从配置的master失效后，sentinel可以选举出一个新的master，用于自动接替原来master的工作，主从配置中的其他redis服务器自动指向新的master同步数据，一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。选举过程中，文件的内容，会被sentinel动态更改。

3.3.1 redis的哨兵模式操作原理

1主节点下线判断

A)每个哨兵通过down-after-milliseconds设置判断自己监控的master是否触发下线；

B)汇总各个哨兵的结果，多个哨兵打成一致意见才能认为mster客观出现宕机。

2.从哨兵中选出兵王

当主节点被判断客观下线以后，各个哨兵节点会进行协商，通过一个Raft算法，先选举出一个领导者哨兵节点，并由该领导者哨兵节点进行failover故障迁移。哨兵文件的内容解析：

1.sentinel26379.log中，选举0664为哨兵王

2.sentinel26380.log中，选举0664为哨兵王 

3.sentinel26380.log中，选举0664为哨兵王

4.raft算法

3.由兵王推动故障切换选出一个新的master

3.1 从剩余健康的slave节点中，按：

1.选择优先级靠前的：redis.conf中slave-priority，或者replica-priority的最高值（数字越小优先级越高）选取

2.选择偏移量最大的

3.选择runid最小的从服务

3.2 sentinel leader会对选举出的新master执行slave of no noe操作

将其提升为master节点；sentinel leader向其他slave发送命令，让剩余的slave成为新的master节点的slave

3.3 将之前已下线的老master设置为新选出master的从节点：

当老master重新上线后，他会成为新master的从节点；sentinel leader会让原来的master降级为slave兵恢复为正常工作。

3.4 redis的哨兵模式优缺点

1.哨兵节点的数量应该为多个，哨兵本身应该是集群，保证高可用

2.哨兵节点的数量应该是奇数

3.各个哨兵节点的配置应一致

4.如果哨兵节点都部署在Docker等容器里面，尤其要注意端口的正确映射，哨兵+主从复制，但不能保证数据零丢失。