Redis入门——哨兵Redis Sentinel基本原理

十元姐姐ヾ(◍°∇°◍)ﾉﾞ

最近忙着搬家，更新的事就暂时搁置了，停更的这段时间看到博客的浏览量直线上升，而且有篇博客还被收入专题，开心之余也倍感鼓励，接下来会努力提升自己，提高文章质量。
之前了解学习了Redis的主从复制，在这种模式下，如果出现主节点因故障不能正常提供服务，需要人为将从节点晋升为主节点，而且同时要通知应用方更新主节点地址，在实际场景中，这种故障处理方式显然是不合理的。Redis 从2.8开始提供了Redis Sentinel（哨兵）架构来解决这种问题。本节主要讲Redis Sentinel的基本实现原理，具体有三个定时监控任务，主观下线和客观下线，Sentinel领导者选举，故障转移（参考付磊、张益军两位大神的《Redis开发与运维》）

三个定时监控任务

一套合理的监控机制是Sentinel节点判定节点不可达的重要保证，Redis通过三个定时监控任务完成对各个节点发现和监控：

1. 每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。

   
   
   定时执行info命令
   
   

   如图，定时任务的作用具体为：

• 通过向主节点Master执行info命令，获取从节点的信息，这也是为什么Sentinel节点不需要显式配置监控从节点（redis.conf配置Sentinel监控主节点Master就行，不需要配置从节点）；
• 当有新的从节点加入时，都可以立刻感知到；
• 节点不可达或故障转移后，可以通过info命令实时更新节点拓扑信息。

2. 每隔2秒，每个Sentinel节点会向Redis数据节点的sentinel:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及他们对主节点的判断，因此这个定时任务可以完成以下两个任务：（画的图好像一个表情Orz）
   
   Sentinel节点发布和订阅__Sentinel__:hello频道

• 发现新的Sentinel节点：通过订阅主节点的sentinel:hello了解其他的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来，并与该Sentinel节点创建连接；
• Sentinel节点之间交换主节点的状态，作为后面讲到的客观下线与领导者选举的依据。

3. 每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。
   
   Sentinel节点向其余节点发送ping命令
   
   如上图（又画了一个表情。。。），通过上面的定时任务，Sentinel节点对主节点、从节点、其余Sentinel节点都建立起连接，实现了对每个节点的监控。这个定时任务是节点失败判定的重要依据

主观下线和客观下线

1. 主观下线
   三个定时任务中的节点信息交流花费的时间超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这种行为称为主观下线。不过听名字就知道这种完全看Sentinel节点的意思，存在误判的可能性。

   
   
   Sentinel节点主观下线检测
2. 客观下线
   当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过（Redis享有选举权的众议院成员，可以这么理解）个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，投票决定选出结果，这样客观得多。
   P.S 从节点、Sentinel节点在主观下线后，没有后续的故障转移操作
   
   Sentinel节点对主节点做客观下线

领导者Sentinel节点选举

抛出一个问题，Sentinel节点对于主节点做了客观下线，是不是我们就可以立即进行故障转移了？NO！实际上故障转移的工作只需要一个Sentinel节点来完成即可。因此需要推出一个来完成故障转移的Sentinel节点，也就是所谓的领导者。
P.S Redis使用了Raft算法去实现领导者选举，本人才疏学浅，还没学通，暂时讲不了〒▽〒
领导者Sentinel选举大致思路为：

1. 每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自身设置为领导者；
2. 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，反之则拒绝；
3. 如果该Sentinel节点发现自己的票数已经大于等于max(quorum, num(sentinels)/2 + 1)，那么它将成为领导者。

每个Sentinel节点只有一票，一旦有一个Sentinel节点获得了max(quorum, num(sentinels)/2 + 1)的票数，则其他Sentinel节点抢票结束，具体可以参考下sentinel.c源码。
选举的过程非常快，一般来说，哪个Sentinel节点率先完成客观下线，哪个就可以成为领导者。

故障转移

Duang~重点来啦(✧◡✧)
领导者Sentinel节点负责故障转移，具体如图：

选出最好的从节点

1. 在从节点列表中选出一个节点作为新的主节点Master，选择方法为：

• 过滤：“不健康”（主观下线、断线）、5秒内没回复Sentinel节点ping响应、与主节点失联超过down-after-milliseconds*10秒；
• 选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续选择；
• 选择复制偏移量最大的从节点（复制最完整的从节点），如果存在则返回，不存在则继续选择；
• 选择runid最小的从节点。

2. Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点
3. Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点
4. Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，等其恢复后命令它去复制新的主节点

小结

Redis Sentinel是Redis的高可用实现方案，包含了故障发现、故障自动转移你、配置中心、客户端通知。预计接下来会出Sentinel的简单部署和开发运维经常出现的问题的文章，大家可以小小期待下（又要爆肝学习了(◎_◎;)）
喜欢文章的小朋友请点赞关注赞赏，谢谢哈