Redis的哨兵机制

主从高可用的问题

• 故障转移问题

基本架构的说明

• 客户端先从sentinel 哪里获取那个是master，或者说是 slave ；
• 然后客户端才会对redis 进行直连操作；
• 流程：
  
• 故障转移流程，选举新的master
  
  注意 一套哨兵机制可以监控多个redis体系

redis sentinel 的安装

模拟部署

Sentinel 的主要配置

• port ${port}
• dir “/opt/soft/redis/data/”
• logfile “${port}.log”
• sentinel monitor masterName 127.0.0.1 7000 2 ------>标明了那个是你的主master，2 代表如果有两个的哨兵发现机器有故障才会进行故障转移；
• sentinel down-after-milliseconds masterName 30000; ----->如果30秒始终ping 不通 ，则证明有故障
• sentinel parallel-sync masterName 1 ; ------>并行复制的时候只能有一个进行；
• sentinel failover-timeout masterName 180000 ; ------>进行故障转移的时间；

客户端的链接流程

• 配置好sentinel节点的集合，和 masterName 的名字；
• 1. 遍历 sentinel节点集合 获取一个可用的sentinel 节点（能够ping通）
     
• 2.通过sentinel获取主节点的地址；
  
• 验证获取到的节点的地址是否是想要的角色
  
• 客户端实时更新主从节点的角色变化；（通过消息订阅的模式实现）
  

sentinel的三个定时任务

• 每一秒每个sentinel对sentinel和redis执行ping ，（观察是否有人下线了）
  
• 每两秒sentinel相互之间交互信息（对redis节点的看法和自身信息）（通过消息订阅模式（通过master节点的channel））
  
• 每十秒sentinel对master，slave执行info ，观察主从关系

sentinel判定的主观下线和客观下线

sentinel 领导者选举

sentinel进行故障转移

合适的节点

节点上线

实现原理

常见的运维开发问题的梳理