Redis7-8.0-哨兵（sentinel）

Redis哨兵（sentinel）

作用：无人值守运维

是什么？

吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将一个从库转换为新主库，继续对外服务

能干什么？

1. 主从监控
   • 监控主从redis库运行是否正常
2. 消息通知
   • 哨兵可以将故障转移的结果发送给客户端
3. 故障转移
   • 如果master异常，则会进行主从切换，将其中一个slave作为新的master
4. 配置中心
   • 客户端通过连接哨兵来获得当前redis服务的主节点地址

怎么用？

哨兵架构说明（6台机器）：

• 3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人
• 1主2从：用于数据读取和存放

默认的sentinel.conf文件内容

• bind
  • 服务监听地址，用于客户端连接，默认本机地址
• daemonize
  • 是否以后台daemonize方式运行
• protected-mode
  • 安全保护模式
• port
  • 端口
• logfile
  • 日志文件路径
• pidfile
  • pid文件路径
• dir
  • 工作目录
• sentinel monitor
  • 设置要监控的master服务器
  • quorum表示最少有几个哨兵认可客观下线，同一故障迁移的法定票数
    • 有的时候网络是不可靠的，一个sentinel会因为网络堵塞误认为一个master已经宕机，在sentinel集群环境下需要多个sentinel相互沟通来确认某个master是否真的已经宕机了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移，因为有的时候sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
• sentinel auth-pass
  • master设置了密码，连接master服务的密码
• 其他
  • 

原理

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

运行流程和故障切换

SDown主观下线（Subjectively Down）：

• 指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）
• SDOWN主观不可用是单个sentinel自己主观上监测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后在一定时间内没有受到合法的回复就视为达到了SDOWN的条件
• sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
  • 
  • sentinel down-after-milliseconds

ODown客观下线（Objectively Down）：

• ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉
• 
  • master-name：是对某个master+slave组合的一个区分标识（一套sentinel可以监听多组master+slave这样的组合）
  • quorum：是进行客观下线的一个依据，也称为法定人数/法定票数，意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移，因为有的时候某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题才可以进行下一步操作，报这个了公平性和高可用。

当主节点被判断为客观下线：各个哨兵节点会进行协商，先选举出一个领导者哨兵节点，并由该领导节点进行故障迁移（failover）

怎么选取出领导者哨兵节点？

Raft算法：

监视该主节点的所有哨兵都有可能被选为领导者哨兵，选举使用的算法是Raft算法，其基本思路是先到先得，即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者

由领导者哨兵节点开始推动故障切换流程并选出一个新的master：

1. 某个slave被选中成为新master

   • 

   • 选出新master的规则（剩余slave节点健康的前提下）：

     • redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点（数字越小优先度越高）

       

     • 复制偏移位置offset最大的从节点

     • 最小Run ID的从节点（字典顺序，ASCII码）

2. 重新确立master

   • 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
   • sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点
   • sentinel leader向其他slave发送命令，让剩余的slave成为新的master节点的slave

3. 之前宕机的master重连后不会成为master

   • 将之前已经下线的老master设置为新选出的新master的从节点，当老master重新上线后，他会成为新master的从节点
   • sentinel leader会让原来的master降级为slave并恢复正常工作

小总结

哨兵使用建议

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
• 哨兵节点的数量应该是奇数个
• 各个哨兵节点的配置应该一致
• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
• 哨兵集群+主从复制，并不能保证数据零丢失