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 哨兵配置

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

具体配置参数整理：

使用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端口

至此，故障转移完成！！

到此这篇关于Redis哨兵模式的实现的文章就介绍到这了,更多相关Redis哨兵模式内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论