一、什么是哨兵

        顾名思义，哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

（1）监控主数据库和从数据库是否正常运行；

（2）主数据库出现故障时自动将从数据库转换为主数据库。

在一个一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健。哨兵不仅会同时监控主数据库和从数据库，哨兵之间也会互相监控。

二、使用哨兵

        建立一个配置文件，如sentinel.conf，内容为：sentinel monitor mymaster 127.0.0.1 6379 1 。其中mymaster 表示要监控的主数据库的名字。后两个参数表示主数据库的地址和端口号。最后1表示最低通过票数。

        启动Sentinel进程，命令为：$redis-sentinel /path/to/sentinel.conf。

        配置哨兵监控一个系统时，只需要配置其监控主数据库即可，哨兵会自动发现所有复制该主数据库的从数据库。当主数据库挂掉时，哨兵会挑选一个从数据库将其升级为主数据库。以前的主数据库恢复后，哨兵会自动将其转换为从数据库并对外提供服务。

三、实现原理

        一个哨兵进程启动时会读取配置文件的内容，通过如下的配置找出需要监控的主数据库：setinel monitor master-name ip redis-port quorum。quorum用来表示执行故障操作前至少需要几个哨兵节点同意。一个哨兵节点可以同时监控多个Redis主从系统，只需要提供多个setinel  monitor配置即可。

        同时多个哨兵节点也可以同时监控同一个Redis主从系统，从而形成网状结构。

        哨兵启动后，会与要监控的主数据库建立两条连接，这两个连接的建立方式与普通的redis客户端无异。其中一条连接用来订阅该主数据库的_sentinel _:hello频道以获取其他同样监控该数据库的哨兵节点的信息，另外哨兵也需要定期向主数据库发送INFO等命令来获取主数据库本身的信息。因为客户端的连接进入订阅模式时就不再执行其他命令了，所以这是哨兵会使用另外一条连接来发送这些命令。

        和主数据库的连接建立完成后，哨兵会定时执行下面3条命令：

（1）每10秒哨兵会向主数据库和从数据库发送INFO命令。

（2）每2秒哨兵会向主数据库和从数据库的_sentinel_:hello频道发送自己的信息。

（3）每1秒哨兵会向主数据库、从数据库和其他哨兵节点发送PING命令。

这三个操作贯穿哨兵进程的整个生命周期。

        首先，发送INFO命令使得哨兵可以获取当前数据库的相关信息（包括运行ID、复制信息等）从而实现新节点的自动发现。前面说配置哨兵监控Redis主从系统时只需要指定主数据信息即可，因为哨兵正是借助INFO命令来获取所有复制该数据库的从数据库信息的。启动后，哨兵向主数据发送INFO命令，通过解析返回结果来得知从数据库列表，而后对每个从数据库同样建立两个连接，两个连接的作用和前文介绍的与主数据库建立的两个连接完全一致。在此之后，哨兵会每10秒定时向已知的所有主从数据库发送INFO命令来获取信息更新并进行相应操作，比如对新增的从数据库建立连接并加入监控列表，对主从数据库的角色变化（由故障恢复操作引起）进行信息更新等。

        接下来哨兵向主从数据库的_sentinel_:hello频道发送信息来同样监控该数据库的哨兵分享同样的信息。消息包括哨兵的基本信息，以及其监控的主数据库的信息。哨兵会订阅每个其监控的数据库的_sentinel_:hello频道，所以当其他哨兵收到消息后，会判断发消息的哨兵是不是新发现的哨兵。如果是，则将其加入已发现的哨兵列表中并创建一个到其的连接（与数据库不同，哨兵与哨兵之间只会创建一条连接用来发送PING命令，而不需要创建另外一条连接来订阅频道，因为哨兵只需要订阅数据库的频道即可自动发现其他哨兵）。同时哨兵会判断信息中主数据库的配置版本，如果该版本比当前记录的主数据库的版本高，则更新主数据库的数据。

        实现了自动发现从数据库和其他哨兵节点后，哨兵要做的就是定时监控这些数据库和节点有没有停止服务。这是通过每隔一定的时间向这些节点发送PING命令实现的。时间间隔与down-after-milliseconds选项有关，当down-after-milliseconds的值大于1秒时，哨兵会每隔down-after-milliseconds指定的时间发送一次PING命令。当超过down-after-milliseconds选项指定时间后，如果被PING的数据库或节点仍然未进行回复，则哨兵认为其主观下线。主观下线表示从当前的哨兵进程来看，该节点已下线。如果该节点是数据库，则哨兵会进一步判断是否需要对节点进行故障恢复：哨兵发送sentinel is-master-down-by-addr命令询问其他哨兵节点以了解他们是否也认为该主数据库已经主观下线，如果达到指定数量时，哨兵会认为其客观下线，并选举领头的哨兵节点对主从系统发起故障恢复。选举领头哨兵的过程使用了Raft算法：

（1）发现主数据库客观下线的哨兵节点向每个哨兵节点发送命令，要求对象选举自己成为领头哨兵。

（2）如果目标哨兵节点没有选过其他人，则会同意将其设置为领头哨兵。

（3）如果其发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵，则其成为领头哨兵。

（4）当有多个哨兵节点同时参选领头哨兵，则会出现任何节点当选的可能。此时，每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。

四、哨兵的部署

        哨兵以独立进程的方式对一个主从系统进行监控，监控效果的好坏与否取决于哨兵的视角是否有代表性。如果一个主从系统中配置的哨兵较少，哨兵对整个系统的判断的可靠性就会降低。极端情况下，当只有一个哨兵时，哨兵本身就可能发生单点故障。整体来讲，相对稳妥的哨兵部署方案是使得哨兵的视角尽可能地与每个节点的视角一致。即，

（1）为每个节点（无论是主数据库还是从数据库）部署一个哨兵。

（2）使每个哨兵与其对应的节点的网络环境相同或相近。

        这样的部署方案可以保证哨兵的视角拥有较高的代表性和可靠性。 同时设置 quorum的值为N/2+1（其中N为哨兵节点数量），这样使得相当大部分哨兵节点同意后才会进行故障恢复。