【Redis学习笔记】第十二章 Redis哨兵模式

---

---

1、哨兵简介

master宕机场景的处理：

问题：

怎么确认master确实宕机了？（中间断网1s就认为人挂了不合适）
怎么找一个slave来暂替master？
旧的master恢复以后怎么处理？

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

哨兵的三点作用：

• 监控
  不断的检查master和slave是否正常运行。
• 通知
  当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
• 自动故障转移
  断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址

注：

• 哨兵也是一台redis服务器，只是不提供数据服务
• 通常哨兵配置数量为单数，3、5、7……

2、启用哨兵模式

2.1 哨兵配置

查看哨兵的配置文件，过滤注释与空行：

具体配置参数整理：

配置项	实例	含义
sentinel auth-pass 服务器名 密码	sentinel auth-pass mymaster 9527	连接服务器时的验证密码
sentinel down-after-milliseconds 自定的服务器名 masterIP Port 票选数量	sentinel monitor mymaster 1.2.3.4 6379 2	后面的2，即两个哨兵认为master挂了就是真的挂了，常为哨兵数的1/2+1
sentinel down-after-milliseconds 服务器名 毫秒数	sentinel down-after-milliseconds mymaster 3000	哨兵判定master挂掉的时间周期
sentinel parallel-syncs 服务器名 服务器数	sentinel parallel-syncs mymaster 1	指定同时进行主从的slave数量，数值越大，要求网络资源越高，数值约小，同步时间约长
sentinel failover-timeout 服务器名 毫秒数	sentinel failover-timeout mymaster 9000	出现故障后，故障切换的最大超时时间3分钟，超过则认定切换失败
sentinel notification-script 服务名 脚本路径		服务器无法正常联通时，设定的执行脚本，通常调试使用

使用sed编辑文件，并重定向。生成三个哨兵的配置文件（用三个不同端口模拟三个哨兵）

哨兵启动指令：

redis-sentinel sentinel-端口号.conf
先启动master、再slave、最后启动哨兵

=====================================================

2.2 哨兵模拟搭建实验

以本机的6379位master、6380、6381为slave，26379、26380、26381为三个sentinel，模拟实验：

①启动master和slave后，启动26379sentinel：

②连接哨兵的客户端，验证其确实不能进行set等指令：


③启动哨兵26380

注意此时哨兵26379的配置文件会相应的发生变化：

④模拟master宕机，CTRL+C掉6379的server端

⑤6379重新连接服务端以后，查看哨兵控制台日志：取消了6379的s_down标记，但并未恢复其master的身份

=====================================================

3、哨兵工作原理

哨兵在进行主从切换过程中经历三个阶段：
 监控
 通知
 故障转移

3.1 监控阶段

sentinel会向master和slave要信息，各个sentinel之间有专门通路进行信息交换，如此便形成了一个网络：

3.2 通知阶段

就像一个小的朋友圈，sentinel之间互相进行信息的传播，保持信息的对等：

3.3 故障转移阶段

①哨兵1持续发消息给master均无反应，标记master为S_DOWN，也叫主观下线

②哨兵1标记后，并将这个消息带回sentinel的圈子里，告诉其余哨兵，可能master挂了，于是其余哨兵开始发送消息给master验证消息是否属实

③验证结果确实如此，只要半数以上哨兵认为挂了，则标记变为O_DOWN（这也是哨兵数量要求奇数的原因），这时，O_DOWN就是客观下线了

④既然确认master挂了，那就要去处理，哪个哨兵去处理呢，每个哨兵发送挂的IP、挂的端口、自己曾经竞选的次数、自己的runID，以便选个领头的哨兵

最后由竞选出来的1号哨兵去处理：

⑤ 从slave中挑选备选master，首先淘汰掉：

• 不在线的
• 响应慢的
• 与原master断开时间久的

对于剩下的备选，则考虑优先级、offset、runid等等

⑥向新选出的master发送slaveof no one，断开原主从连接，并向其他slave发送slaveof 新masterIP端口

至此，故障转移完成！！