1、哨兵机制简介

哨兵机制由一个或多个哨兵服务器组成，哨兵机制可以监视任意多个主服务器，以及这些主服务器属下所有的从服务器，并在被监视的主服务器进入下限状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。假设主服务器为server1，从服务器为server2，server3，server4，如果主服务器server1下线，哨兵机制会对server1进行故障转移操作：

首先，哨兵系统会选择server1下属的一个从服务器，并将这个被选中的从服务器升级为新的主服务器；
接着，哨兵系统会向server1下属的所有从服务器发送新的复制命令，让它们成为新的主服务器的从服务器，当所有从服务器都开始复制新的主服务器时，故障转移操作执行完毕；
最后，哨兵机制会继续监视已下线的server1，并在它重新上线时，将它设置为新的主服务器的从服务器；

2、初始化哨兵服务器

启动命令：

$ redis-sentinel sentinel.conf
或
$ redis-server sentinel.conf --sentinel

当一个哨兵服务器启动时，它需要执行以下步骤：

初始化服务器：哨兵服务器本质上只是一个运行在特殊模式下的Redis服务器，只是哨兵服务器和普通服务器的工作不同。例如哨兵服务器不会载入RDB或者AOF文件。
将普通Redis服务器使用的代码换成Sentinel专用代码：例如哨兵服务器和端口号为26379，哨兵服务器的命令表和普通服务器的命令表也不同。
初始化Sentinel状态：初始化sentinelState的结构体，这个结构保存了服务器中所有和哨兵功能有关的状态。
根据给定的配置文件，初始化Sentinel的监视主服务器的列表：服务器状态中字典master记录了所有被Sentinel监视的主服务器相关信息。其中字典的键是被监视主服务器的名字，而字典的值则是被监视主服务器对应的sentinelRedisInstance实例，每个实例可以是主服务器、从服务器或者另外一个Sentinel。
创建连向主服务器的网络连接：对于每个被哨兵监视的主服务器来说，哨兵服务器会创建两个连向主服务器的异步网络连接：第一个是命令连接，用于向主服务器发送命令，并接收命令回复；第二个是订阅连接，这个连接专门用于订阅主服务器的__sentinel__:hello频道。

3、获取主服务器和从服务器信息

3.1 获取主服务器信息

哨兵服务器会以每10s一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。通过分析主服务器返回的INFO命令回复，Sentinel可以获取以下两方面信息：

一方面是关于主服务器本身的信息，包括服务器运行ID和服务器角色等。
另一方面是关于主服务器属下所有从服务器的信息。根据这些信息，Sentinel无需用户提供从服务器的地址信息，就可以自动发现从服务器。

3.2 获取从服务器信息

当哨兵服务器发现有新的从服务器出现时，哨兵除了会为这个新的从服务器创建相应的实例结构外，哨兵还会创建到从服务器的命令连接和订阅连接。

4、向主服务器和从服务器发送频道信息

默认情况下，哨兵会以2s一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送命令，这个命令向服务器的__sentinel__:hello频道发送一条信息，信息的内容由多个参数组成：

其中以s_开头的参数记录的是哨兵本身的信息
而以m_开头的参数记录的则是主服务器的信息。

5、接收来自主服务器和从服务器的频道信息

当哨兵和一个主服务器或者从服务器建立起订阅连接后，哨兵就会通过订阅连接，向服务器发送以下命令：

SUBCRIBE __sentinel__:hello

哨兵对 __sentinel__:hello频道的订阅会一直持续到哨兵和服务器的断开为止。也就是说，对于每个与哨兵连接的服务器，哨兵既通过命令连接向服务器的__sentinel__:hello频道发送信息，又通过订阅连接从服务器的__sentinel__:hello频道接收信息。

对于监视同一个服务器的多个哨兵来说，一个哨兵发送的信息会被其他哨兵接收到，这些信息会被用于更新其他哨兵对发送信息哨兵的认知，也会被用于更新其他哨兵对监视服务器的认知。

此外，当哨兵通过频道信息发现一个新的哨兵时，它不仅会为新的哨兵在sentinel字典中创建相应的实例结构，还会创建一个连向新哨兵的命令连接，而新哨兵也会同样创建连向这个哨兵的命令连接，最终监视同一个主服务器的多个哨兵将形成相互连接的网络：哨兵A有连接哨兵B的命令连接，哨兵B也有连接哨兵A的命令连接。

6、检测主观下线状态和客观下线状态

6.1 检测主观下线状态

在默认的情况下，哨兵会以每秒一次的频率向所有与他建立了命令连接的实例（包括主服务器、从服务器、其他哨兵在内）发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。实例对PING的回复可以分为以下两种情况：

有效回复：实例返回+PONG、-LOADING、-MASTERDOWN三种回复的其中一种
无效回复：除了有效回复之外的其他回复，或者在指定时限内没有返回任何回复

哨兵配置文件down-after-milliseconds选项指定了哨兵判断实例进入主观下线所需要的时间长度：如果一个实例在down-after-milliseconds毫秒之内，连续向哨兵返回无效回复，那么哨兵会修改这个实例所对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来表示这个实例已经进入主观下线状态。

6.2 检测客观下线状态

当哨兵将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线，它会向同样监视这一主服务器的其他哨兵进行询问，看它们是否也认为主服务器已经进入了下线状态。当哨兵从其他哨兵那里接收到足够数量的已下线判断后，哨兵会将主服务器判定为客观下线，并对主服务器执行故障转移操作。

7、选举领头的哨兵

当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个哨兵会进行协商，选出一个领头的哨兵，并由领头哨兵对下线的主服务器执行故障转移操作。选举规则比较复杂，这里不详述。

8、故障转移

该操作包含三个步骤，分别是：

在已下线的主服务器的从服务器里面，挑选一个从服务器，并将其转换为主服务器
让已下线主服务器的从服务器改为复制新的主服务器
将已下线的主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器。

参考：《Redis设计与实现》

Redis（七）：Redis的哨兵机制