Redis哨兵

当主数据库遇到异常中断服务后,我们需要将宕机的master下线，然后找一个slave作为master，并且通知所有点的slave连接新的master。之后启动就可以了。

哨兵

上面的操作，通过哨兵就可以解决。
哨兵是一个用于对主从结构中每台服务器的监控，当出现故障的时候通过投票机制来选择新的master并且将所有的slave连接到新的master。

通过上面的理解，我们知道哨兵主要就是

• 监控
• 通知
• 自动故障转移

需要我们了解的是哨兵也是一台redis服务器，只是不提供数据服务。
通常将哨兵数量为多个，并且配置为单数。

通过如下命令来启动。

redis-sentinel sentinel-端口号.conf

阶段一监控阶段

sentinel首先通过info获取master信息。然后建立了一个cmd的连接，专门用来发送命令。
在此过程中，
哨兵端保存了获取到master所有的状态的信息（master slave sentinel）。
master也会保存redis实例的信息（master slave sentinel）。
由于master中会保存slave的相应状态。所以接着哨兵通过info来向各个slave获取相应更完整的信息。

当有第二个sentinel的时候，它也会向master获取信息。但是获取的时候会查看master中保存的__sentinel__信息。然后接着保存（master slave__sentinel__）。
由于sentinel保存的__sentinel__和第一个__sentinel__保存的不一样。sentinel之间通过发布订阅来同步信息。
通过ping命令来进行保证信息对称。

阶段二：通知阶段

每隔几秒哨兵会向master和slave的__sentinel__:hello 频道发送自己的信息。

阶段三：故障转移阶段

发现问题

如果发送__sentinel__:hello master没有进行通信。则在master中标记一个状态sri_s_down。
如果超过一定时间没有回复，哨兵结点就会将其进行主观下线。

哨兵通过sentinel is-master-down-by-addr命令询问其他sentinel的状态。

当超过一定数值哨兵都确认master连接不上之后，master就保存一个状态sri_o_down。这个叫客观下线。

注意：
这里面说的都是master节点。slave节点与哨兵发生故障，被主观下线之后，不会再有后续的客观下线和故障转移。

竞选负责人

当master被判断客观下线以后，各个哨兵结点会进行协商，选举出一个领导哨兵节点，并且有该领导者节点进行故障转移操作。

监视该主节点的所有哨兵都有可能被选为领导者
选举用的算法那是raft算法：
Raft算法的基本思想就是先到先得：即在一轮的选举中，哨兵A想B发送称为领导者的申请，如果B没有同意过其他的哨兵，就会同意A为领导者。一般来说，先完成客观下线，就能称为领导者。

如下raft动画可以对raft算法有个更好的理解：
raft动画

开始转移

故障转移：选举出的领导者哨兵开始进行故障转移操作大致分为3个步骤：
在slave节点中选择新的master

1.首先过滤掉不健康的从节点
2.然后选择优先级最高的从节点（有replica-prority指定）；如果优先级无法区分，
3.则选择复制偏移量(offset)最大的从节点。如果仍然无法区分，
4.则选择runid最小的从节点。

更新主从状态：

通过slaveof no one命令让选出来的从节点（slave）称为主节点(master)
并通过SLAVEOF命令来让其他节点称为其从节点。

将已经下线的主节点保持关注，当已经下线的主节点重新上线后设置为新的主节点的从节点。