Yml redis 哨兵模式 redis 哨兵模式原理

1. 哨兵是什么？

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

2.配置哨兵有什么作用？

• 监控

• 不断地检查master和slave是否正常运行
• master存活检测、master与slave运行情况检测

• 通知（提醒）

• 当被监视的服务器出问题的时候，向其它（哨兵间，客户端）发送通知。

• 自动故障转移

• 断开master与slave连接，选区一个slave作为master，将其它slave连接到新的master，并告知客户端新的服务器地址

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

3.怎么配置？

配置过程：

在此基础上，把所有配置文件的 daemonize yes 改为 daemonize no ，还要加上 logfile "" 这个配置

daemonize no表示前台运行，logfile ""

4.配置文件主要参数说明

• 后面的2表示，哨兵通过监控，如果有2个或2个以上的哨兵认为master挂了，就真的挂了，接下来会进行通知和故障转移操作，通常设置为哨兵数量的一半以上，例如7个哨兵设置为4，9个哨兵设置为5，11个哨兵设置为6

sentinel monitor mymaster 10.211.55.11 6380 2

• 哨兵连接master的时候，连接超过30000毫秒(30秒)没有响应，则认为master挂了

sentinel down-after-milliseconds mymaster 30000

• 后面这个1表示，当master宕机以后，进行主从切换时，最多可以有多少个slave同时对新的master进行同步，设置的越大，同步时间越短，但是服务器压力越大，设置的越小，同步时间越长，服务器压力越小

sentinel parallel-syncs mymaster 1

• 180000（180秒）表示同步数据的时候，多长时间内同步完成算有效，超过这个时间就会出现同步超时

sentinel failover-timeout mymaster 180000

5.工作原理是什么？

哨兵模式开启以后，如果发生了master宕机的情况，执行主从切换操作，其操作分为以下3部分

• 监控
• 通知
• 故障转移

 

阶段一：监控阶段

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

• 获取各个sentinel的状态（是否在线，ping命令）
• 获取master的状态（info命令）

• master属性

• runid
• role: master

• 各个slave的详细信息

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

• slave属性

• runid
• role：slave
• master_host、master_port
• offset

 

• sentinel会向master、slave以及其它sentinel获取状态
• sentinel之间会组建“对应频道”，大家一起发布信息、订阅信息、收集信息、同步信息等

 

 

阶段二：通知阶段

• 其中一个sentinel抢先给每个节点发送hello，看有没有那个服务器宕机了，如果一切正常，就给其它sentinel通知正常

 

阶段三：故障转移阶段

确认master是否真的宕机

1. sentinel1一直向master发送hello，发现没有响应
2. sentinel1获取到flags:SRI_S_DOWN的信息，主观判断master已经挂了
3. 给其它的sentinel发送SENTINEL is-master-down-by-addr ........ ，也就是说，告诉其它sentinel，master已经挂了
4. 其它sentinel不轻易相信sentinel1，于是好奇，给master发送hello，探测一下master是不是真的挂了
5. 由于超过半数的sentinel都说master挂了，那么master就真的挂了，更新SentinelRedisInstance的master信息为flags:SRI_O_DOWN

 

 

投票选举一个sentinel去进行主从切换的处置操作

五个哨兵在微信群上各自发送一条消息，每个哨兵既参与竞选又参与投票

投票规则是这样的：在一个时刻里面，谁先收到哪个发送者的信息，谁就投票给哪个发送者，假设在极短的时间内，只有sentinel1和sentinel4的网络状态非常良好，于是比其它sentinel先发出消息了，这时候，sentinel2最先接收到sentinel1的信息，sentinel4慢了一步，所以sentinel2会给sentinel1投票，sentinel1的票数+1。

按照这个规则去投票，票数最多的那个sentinel被安排主从切换的处置操作~

主从切换的处置操作

备选原则如下列表：

• 服务器列表中挑选备选master

• 在线的（保留）
• 响应慢的（被OUT）
• 与原master断开时间久的（被OUT）
• 优先原则

• 优先级（优先级高的保留）
• offset（偏移量小的保留）
• runid（runid小的保留）

• 发送指令

• 向新的master发送slaveof no one，告知新的master，恭喜你，你当上领导了~
• 向其它slave发送slaveof新master 的IP和端口，告知各位slave兄弟们，你们去连接新的master吧！！

 

slave1和slave2设置的优先级一样，那么就要看谁的偏移量offset更小，数据同步性更强，就选谁，但这两个slave的偏移量一样，那么看谁的runid小就选谁为master