Redis入门——哨兵Redis Sentinel基本原理
十元姐姐ヾ(◍°∇°◍)ﾉﾞ
最近忙着搬家，更新的事就暂时搁置了，停更的这段时间看到博客的浏览量直线上升，而且有篇博客还被收入专题，开心之余也倍感鼓励，接下来会努力提升自己，提高文章质量。
之前了解学习了Redis的主从复制，在这种模式下，如果出现主节点因故障不能正常提供服务，需要人为将从节点晋升为主节点，而且同时要通知应用方更新主节点地址，在实际场景中，这种故障处理方式显然是不合理的。Redis 从2.8开始提供了Redis Sentinel（哨兵）架构来解决这种问题。本节主要讲Redis Sentinel的基本实现原理，具体有三个定时监控任务，主观下线和客观下线，Sentinel领导者选举，故障转移（参考付磊、张益军两位大神的《Redis开发与运维》）
三个定时监控任务
一套合理的监控机制是Sentinel节点判定节点不可达的重要保证，Redis通过三个定时监控任务完成对各个节点发现和监控：
-
每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构。
定时执行info命令
如图，定时任务的作用具体为：
- 通过向主节点Master执行info命令，获取从节点的信息，这也是为什么Sentinel节点不需要显式配置监控从节点（redis.conf配置Sentinel监控主节点Master就行，不需要配置从节点）；
- 当有新的从节点加入时，都可以立刻感知到；
- 节点不可达或故障转移后，可以通过info命令实时更新节点拓扑信息。
- 每隔2秒，每个Sentinel节点会向Redis数据节点的sentinel:hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及他们对主节点的判断，因此这个定时任务可以完成以下两个任务：（画的图好像一个表情Orz）
Sentinel节点发布和订阅__Sentinel__:hello频道
- 发现新的Sentinel节点：通过订阅主节点的sentinel:hello了解其他的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来，并与该Sentinel节点创建连接；
- Sentinel节点之间交换主节点的状态，作为后面讲到的客观下线与领导者选举的依据。
- 每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。
Sentinel节点向其余节点发送ping命令
如上图（又画了一个表情。。。），通过上面的定时任务，Sentinel节点对主节点、从节点、其余Sentinel节点都建立起连接，实现了对每个节点的监控。这个定时任务是节点失败判定的重要依据
主观下线和客观下线
-
主观下线
三个定时任务中的节点信息交流花费的时间超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这种行为称为主观下线。不过听名字就知道这种完全看Sentinel节点的意思，存在误判的可能性。
Sentinel节点主观下线检测
- 客观下线
当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过<quorum>（Redis享有选举权的众议院成员，可以这么理解）个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，投票决定选出结果，这样客观得多。
P.S 从节点、Sentinel节点在主观下线后，没有后续的故障转移操作
Sentinel节点对主节点做客观下线
领导者Sentinel节点选举
抛出一个问题，Sentinel节点对于主节点做了客观下线，是不是我们就可以立即进行故障转移了？NO！实际上故障转移的工作只需要一个Sentinel节点来完成即可。因此需要推出一个来完成故障转移的Sentinel节点，也就是所谓的领导者。
P.S Redis使用了Raft算法去实现领导者选举，本人才疏学浅，还没学通，暂时讲不了〒▽〒
领导者Sentinel选举大致思路为：
- 每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线，会向其他Sentinel节点发送
sentinel is-master-down-by-addr命令，要求将自身设置为领导者； - 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的
sentinel is-master-down-by-addr命令，将同意该请求，反之则拒绝； - 如果该Sentinel节点发现自己的票数已经大于等于max(quorum, num(sentinels)/2 + 1)，那么它将成为领导者。
每个Sentinel节点只有一票，一旦有一个Sentinel节点获得了max(quorum, num(sentinels)/2 + 1)的票数，则其他Sentinel节点抢票结束，具体可以参考下sentinel.c源码。
选举的过程非常快，一般来说，哪个Sentinel节点率先完成客观下线，哪个就可以成为领导者。
故障转移
Duang~重点来啦(✧◡✧)
领导者Sentinel节点负责故障转移，具体如图：
选出最好的从节点
- 在从节点列表中选出一个节点作为新的主节点Master，选择方法为：
- 过滤：“不健康”（主观下线、断线）、5秒内没回复Sentinel节点ping响应、与主节点失联超过down-after-milliseconds*10秒；
- 选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续选择；
- 选择复制偏移量最大的从节点（复制最完整的从节点），如果存在则返回，不存在则继续选择；
- 选择runid最小的从节点。
- Sentinel领导者节点会对第一步选出来的从节点执行
slaveof no one命令让其成为主节点 - Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点
- Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，等其恢复后命令它去复制新的主节点
小结
Redis Sentinel是Redis的高可用实现方案，包含了故障发现、故障自动转移你、配置中心、客户端通知。预计接下来会出Sentinel的简单部署和开发运维经常出现的问题的文章，大家可以小小期待下（又要爆肝学习了(◎_◎;)）
喜欢文章的小朋友请点赞关注赞赏，谢谢哈
