十九、Redis进阶-Redis哨兵模式原理
从上一篇文章中实现的哨兵，可以有这样的总结，当主数据库宕机之后，哨兵会推选出一个新的主服务器，并把之前的主服务器变为新的从服务器。这一过程是哨兵自动完成的，不需要人工参与。
如果没有哨兵就需要人工参与，这一过程是比较繁琐的，可见哨兵模式的方便。那么什么是哨兵？
什么是哨兵
哨兵的作用的是用来监控Redis系统的运行状态。功能如下：
1）监控主数据库与从数据库是否正常运行
2）主数据库出现故障时自动将从数据库切换为主数据库。
哨兵是一个独立的进程，可以使用一个哨兵也可以使用多个哨兵进行监控，实际使用环境中使用多个哨兵（建议奇数）进行监控。
哨兵实现原理
一个哨兵进程启动之后会读取配置文件的内容，通过如下配置的内容找出需要监控的主数据库：sentinel monitor master-name ip redis-port quorum
一个哨兵节点可以同时监控多个Redis主从系统，其配置如下：
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel monitor othermaster 127.0.0.1 6380 2
多个哨兵同时监控一个Redis主从系统。上一篇文章记录的就是多个哨兵监控一个主从。
配置含义解释
sentinel monitor mymaster 127.0.0.1 6379 2
mymaster 表示要监控的主数据库名字。可以自定义，名字必须由小写字母、数字和'.-_'组成
127.0.0.1 表示主数据库地址
6379 表示主数据库端口号
2 表示最低通过票数。如当为3哨兵时，有2个认为主数据库挂了，那就是挂了
sentinel down-after-milliseconds mymaster 60000 每隔一秒发送一次ping命令
sentinel down-after-milliseconds othermaster 10000 每陋600毫秒发送一次ping命令
启动信息解释
+slave 表示发现了新的从数据库；
+sdown 表示哨兵主观认为主数据库停止了服务
_odown 表示哨兵客观认为主数据库停止了服务
+try-failover 表示哨兵开始进行故障恢复
+failover-end 表示哨兵完成故障恢复，期间涉及的内容比较复杂，包括领头哨兵的选举、备选数据库的选择等
+switch-master 表示主数据库人6379端口切换到6381端口，即6381升级为主数据库
举个栗子：当6380宕机后，推选出6381作为主数据库，此时6379还是宕机状态，当6379恢复之后，会转变为6381端口实例的从数据库来运行，因此，哨兵将6379的实例信息修改为了6381的从数据库。
哨兵原理可以理解为三个步骤：监控、通知、故障转移
监控
哨兵启动后，会与监控的主数据库建立两条连接，其中一条用来订阅该主数据的__sentinel__:hello频道以获取其他同样监控该数据库的哨兵节点的信息，哨兵也需要定期向主数据库发送INFO等命令来获取主数据库本身的信息。和主数据库建立连接完成之后，哨兵会使用另外一条连接来发送命令：
1）每10秒哨兵会向主数据库和从数据库发送INFO命令
2）每2秒哨兵会向主数据库和从数据库发送sentinel:hello 频道发送自己的信息
3）每1秒哨兵会向主数据库、从数据库和其他哨兵节点发送PING命令。
详解理解上面3步：
首先：发送INFO命令使得哨兵可以获得当前数据库相关信息（运行ID、复制等）从而实现新节点的自动发现。哨兵借助INFO命令来获取所有复制该主数据库的从数据库信息；
其次：启动会，哨兵向主数据库发送INFO命令，通过解析返回结果来得知从数据库列表，然后对每个从数据库建立两个连接；
其三：哨兵会每10秒定时向已知的所有主从数据库发送INFO命令来获取信息更新并进行相应的操作；
其四：哨兵向主从数据库的sentinel:hello频道发送信息与同样监控该数据的哨兵分享自己的信息；发送消息内容为<哨兵地址>,<哨兵端口>,<哨兵的运行ID>,<哨兵的配置版本>,<主数据库名字>,<主数据库地址>,<主数据库端口>,<主数据库配置版本>
通知
配置完成就会进行监控，并发送PING命令。
当超过down-after-milliseconds指定的时间后，如果被PING的数据库或节点没有进行回复，哨兵认为主观下线。
主观下线表示从当前的哨兵进程来看，该节点已经下线。如果该节点为主数据库，则哨兵进行下一步判断是否进行故障恢复：哨兵发送sentinel is-master-down-by-addr命令通知其他哨兵节点，说：我发现这个地址的主数据库下线了，你们来看看是不是下线了，当指定达到指定数量的哨兵也认为主数据库下线了，那么哨兵就认为这是客观下线。
故障转移
哨兵确定主数据库下线之后，会进行内部投票，选出一个领头羊，故障恢复就由这个选出的领头羊来操作，领头羊的选举有如下过程：
1）发现主数据库客观下线的哨兵节点（A节点）向每个哨兵节点发送命令，要求对方选自己成为新的领头哨兵
2）如果目标哨兵节点没有选择过其他哨兵，则同意A成为领头哨兵
3）如果A节点发现有超过半数且超过quorum参数值的哨兵节点同意自己成为领头羊哨兵，那么A成功成为领头羊哨兵
4）当有多个哨兵节点同时参选领头羊哨兵，则会出现没有任何节点当选的可能。此时每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到成功为止
5）选出领头羊哨兵之后，领头羊哨兵开始对主数据库进行故障恢复，内容如下：
5.1）所有在线的从数据库中，选择有限级最高的从数据库。优先级通过slave-priority来设置
5.2）如果有多个最高优先级的从数据库，则复制命令的偏移量越大越优先
5.3）如果条件都一样，则选择运行ID较小的从数据库
选出一个从数据库后，领头羊哨兵向从数据库发送replicaof no one命令使其升级为主数据库。而领头羊向其他从数据库发送repliaof命令使其成为新主数据库的从数据库。最后进行更新内部记录，将已经停止服务的旧主数据库更新为新的从数据库身份继续服务。
我是夕阳何处寻，期待和优秀的你一起同行!
小白
2020年09月06日