絮絮叨叨：Sentinel是基于主从复制的，大家在学习哨兵模式之前，应该具备主从复制的基础，可以阅读我的这篇文章：Redis主从复制 Replication
接下来正式进入正文，本文主要说明 Sentinel如何感知服务器，如何认定主服务器下线，以及如何选举新的主服务器过程。
目录
7.1? 发送 SENTINEL is-master-down-by-addr 命令
7.2? 接收?SENTINEL is-master-down-by-addr 命令
7.3? 接收 SENTINEL is-master-down-by-addr 命令回复
1? Sentinel主要工作流程
Sentinel 哨兵是Redis的高可用解决方案：Sentinel系统是由一系列Sentinel实例组成的，负责监视任意多个主服务器，以及主服务器属下的所有从服务器。如下图，双环（sever1）的是主服务器，单环是主服务器从属的从服务器（server2、sever3、server4）
?当监察到主服务器下线：
?sentinel系统就会自动在从服务器中挑选一个升级为新的主服务器，代替已下线的旧主服务器，并让其他从服务器成为新主服务器的从服务器。
?当旧的主服务器上线后，降级为新的主服务器的从服务器
?这样，就实现了故障转移，实现高可用。接下来说一下实现细节。
2? 启动Sentinel
启动一个sentinel的方法和启动一个服务器差不多。有2种方式启动：
# 第一种
redis-sentinel /path/to/sentinel.conf
# 第二种
redis-server /path/to/sentinel.conf --sentinel主要配置项有：
# 启动端口号
port 26379
# mymaster: 主服务器名(就是一个别名，任意取，但是必须唯一不能重复，可以同时监视任意多个主服务器)
# 10.0.2.39: 主服务器IP
# 6379: 主服务器端口
# 2: 超过2个哨兵认为服务器主观下线，那么则可以认为这个服务器客观下线
sentinel monitor mymaster 10.0.2.39 6379 2
# mymaster 服务器超过30秒没有心跳，则认为主观下线
sentinel down-after-milliseconds mymaster 30000
# ....更多可以查看redis官网描述
启动后，sentinel将会做一系列初始化工作，其中包括根据配置文件，初始化监视的主服务器列表，并且建立连接。
比如有两个服务器 master1 和 master2 配置如下：
?sentinel 自身状态结构 sentinelState?有一个字典masters 专门用于保存监视的主服务器列表，其中masters字典的键为对应配置的主服务器别名，值为sentinelInstance结构，保存IP，端口等信息。
随后，sentinel会与每个被监视的主服务器创建2条异步网络连接：
- 有个是命令链接，用户向主服务器发送命令，并接收回复
- 一个是订阅链接，用户订阅主服务器的 __sentinel__:hello 频道
3? 获取主服务器信息，感知从服务器
sentinel与masters字典中保存的主服务器建立连接后，会以每10秒一次的频率向主服务器发送INFO命令，获取主服务器的信息
?如果主服务器master有3个从服务器slave0,slave1,slave2，那么sentinel将会收到master1的回复
?分析上面内容，可以获取如下信息：
- 获取主服务器运行id，以及角色
- 获取主服务器从属的从服务器信息，包括IP地址和端口号，这样sentinel无须用户提供从服务器的地址信息就可以自动发现从服务器
根据主服务器返回的slaves信息，sentinel将会用于更新主服务器实例结构的slaves字典，该字典记录了对应了主服务器属下的所有从服务器名单：
?
字典记录了对应了主服务器属下的所有从服务器名单：
- 字典的键由 ip:port 组成，对于 127.0.0.1 和 11111 的从服务器来说，则是 127.0.0.1:11111；
- 字典的值则是从服务器对应的实例结构；sentinel在分析INFO命令返回包含的从服务器信息时，会检查是否已存在slaves字典中，如果存在则继续更新，否则创建。
4? 获取从服务器信息
sentinel发现主服务器出现新的从服务器时，不仅会创建对应的实例结构，还会创建连接到从服务器的命令连接和订阅连接，和主服务器的操作一样。
?和主服务器一样，sentinel同样以每10秒1次的频率向从服务器发送INFO命令，获取从服务器的信息，并获得类似回复
?可以通过INFO命令回复提取到以下信息：
- 从服务器的运行id和角色? (用于后续选举新主服务器用)
- 从服务器的IP地址和端口
- 从服务器的优先级 slave_priority?? (用于后续选举新主服务器用)
- 从服务器的复制偏移量 slave_repl_offset? (用于后续选举新主服务器用)
根据这些信息，更新从服务器的实例结构，例如：
?
5? 感知其他sentinel
回忆一下，sentinel除了和主、从服务器建立命令连接，另外还建立了订阅连接，主要作用就是用来发现、更新其他sentinel信息，以及更新被监视的服务器的认知。
默认情况下，sentinel每2秒一次向主、从服务器发布一次消息，如果sentinel正在监视的是主服务器那么m_就是master的信息，如果是从服务器，那么就是从服务器的信息。
PUSHLISH __sentinel__:hello "sentinel_ip"
"sentinel_port"
"sentinel_runid"
"sentinel_epoch"
"m_name"
"m_ip"
"m_port"
"m_epoch"如这条实例表示：
- sentinel IP为127.0.0.1，端口号为26379，运行ID为e955，当前配置纪元为0
- 主服务器名为 mymaster，IP为127.0.0.1，端口号为6379，当前配置纪元为0
?对于监视同一个服务器的其他sentinel来说，也会接收到这条消息，如此其他sentinel就可以感知到有其他sentinel的存在，并保存下来。
如有3个sentinel组成sentinel系统，sentinel1，sentinel2，sentinel3，正在监视同一个服务器，那么当sentinel1向服务器 __sentinel__:hello 发送一条消息时，sentinel2和sentinel3还有sentinel1自己也都会接收到这条消息。
?
当sentinel从__sentinel__:hello中接收到一条消息时，可以从消息中提取到发送这条消息的源sentinel地址，sentinel端口号，运行ID等参数，并进行检查：
- 检查运行ID，如果和自己的相同，则说明是自己发送的，丢弃
- 反之，如果和自己的运行ID不一样，说明是正在监视同一服务器的其他sentinel发送过来的，接收信息的sentinel根据这些参数对主服务器的实例结构进行更新。
如三个sentinel正在监视主服务器mymaster，那么当sentinel 127.0.0.1:26379接收到以下信息时
将执行以下操作：
- 识别到 127.0.0.1:26379是自己，丢弃；
- 识别到 127.0.0.1:26380,?127.0.0.1:26381，根据提取的信息保存在sentinels字典中；?
如sentinel1?127.0.0.1:26379 监视的主服务器mymaster对应数据结构如下
?这样，sentinel系统就通过 __sentinel__:hello 频道实现了互相发现的功能。随后，sentinel会向发现的其他sentinel建立一条命令连接，用户发送命令给其他sentinel，并且接受响应。
需要注意的是，sentinel和sentinel之间只会创建命令连接，不会创建订阅连接，因为订阅连接主要用来发现其他sentinel，只要和主从服务器之间创建就可以实现该功能，所以没有必要。
6? 检查主观下线状态
回顾以下前面的配置项
# mymaster 服务器超过30秒没有心跳，则认为主观下线
sentinel down-after-milliseconds mymaster 30000?默认情况下，sentinel会每秒1次向所有和它创建了连接的实例（主服务器，从服务器，其他sentinel）发送PING连接，并通过实例返回的内容判断是否在线：
- 有效回复：PONG、LOADING、MASTERDOWN
- 无效回复：除了有效回复外的其他回复
如果在配置项 down-after-milliseconds 规定的时间内，如30秒，连续回复返回无效回复，那么sentinel会认为这个实例已经下线，即【主观下线】，需要注意的是，不同sentinel使用的配置文件不同，有可能出现sentinel1认为mymaster下线了，但是sentinel2认为还没有下线。
所以【主观下线】状态并不是最终的状态，还需要跟其他sentinel发起投票。
7? 检查客观下线状态
当认为sentinel认为某服务器主观下线后，需要继续向其他sentinel询问，是否也认为该服务器已下线，如果满足配置项 monitor?的数量，那么则认为该服务器客观下线，进行下一步故障转移操作。
# mymaster: 主服务器名(就是一个别名，任意取，但是必须唯一不能重复，可以同时监视任意多个主服务器)
# 10.0.2.39: 主服务器IP
# 6379: 主服务器端口
# 2: 超过2个哨兵认为服务器主观下线，那么则可以认为这个服务器客观下线
sentinel monitor mymaster 10.0.2.39 6379 27.1? 发送 SENTINEL is-master-down-by-addr 命令
sentinel认为主服务器主观下线后，会使用
SENTINEL is-master-down-by-addr ip port current_epoch runid
- current_port：表示当前配置的纪元，可以当作一个计数器，没什么特别意义
- runid: 表示sentinel运行ID，询问阶段时值为*，选举零头sentinel时，值为零头sentinel的id
例如，被sentinel认为下线的主服务器ip为127.0.0.1，端口为6379，当前配置纪元为0，那么它将会向其他sentinel发送一条消息：
7.2? 接收?SENTINEL is-master-down-by-addr 命令
其他sentinel接收到这条消息，则会检查这个服务器是否确实已经下线了（同样根据配置项down-after-milliseconds），随后回复源sentinel
- down_state: 返回检查结果，1代表已下线，0代表未下线
- leader_runid: 投票阶段值为*，选举阶段值为局部领头sentinel id
- leader_epoch: 局部领头的配置纪元号，只有当leader_runid的值不为*时有效
如
1) 1
2) *
3) 0说明该sentinel同意该主机已下线
7.3? 接收 SENTINEL is-master-down-by-addr 命令回复
源sentinel根据其他sentinel返回的结果统计，如果满足客观下线需要的数量时，则进行下一步故障转移工作。注意，每个sentinel客观下线需要的票数不同，因为它们可能由不同配置文件启动的，主要由配置项决定。
# mymaster: 主服务器名(就是一个别名，任意取，但是必须唯一不能重复，可以同时监视任意多个主服务器)
# 10.0.2.39: 主服务器IP
# 6379: 主服务器端口
# 2: 超过2个哨兵认为服务器主观下线，那么则可以认为这个服务器客观下线
sentinel monitor mymaster 10.0.2.39 6379 28? 选举领头sentinel
当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个sentinel会进行协商，选举一个领头，并由领头来进行下一步故障转移操作。
选举算法如下：在同一个配置纪元里，每个sentinel有发起让其他sentinel选择自己的权力，每个sentinel都有可能被选举为局部leader，规则是先到先得，最先向目标sentinel发送设置要求的源sentinel成为目标sentinel的局部leader，之后的所有请求都会被目标sentinel拒绝。如果某个sentinel被半数以上的sentinel设置为局部leader，那么它就是这个纪元中的唯一leader，有且只有一个。如果选举失败，那么继续下一个纪元的选举，直到选出leader为止。
9? 故障转移
当选举完局部sentinel leader后，sentinel leader将会对已下线的主服务器进行故障转移操作，包括三个步骤：
- 在已下线的主服务器从属的从服务器中，选出一个从服务器，并转换为主服务器
- 让已下线的主服务器从属的从服务器，全部改为复制新选出来的主服务器
- 让已下线的主服务器上线后，改为新主服务器的从服务器。
9.1? 选举新主服务器
选举新主服务器将会从下面条件中选择，权重从高到低：
- 首先，选择优先级高的从服务器，对应配置项?replica-priority?
# The replica priority is an integer number published by Redis in the INFO
# output. It is used by Redis Sentinel in order to select a replica to promote
# into a master if the master is no longer working correctly.
#
# A replica with a low priority number is considered better for promotion, so
# for instance if there are three replicas with priority 10, 100, 25 Sentinel
# will pick the one with priority 10, that is the lowest.
#
# However a special priority of 0 marks the replica as not able to perform the
# role of master, so a replica with priority of 0 will never be selected by
# Redis Sentinel for promotion.
#
# By default the priority is 100.
replica-priority 100- 其次选择复制偏移量大的从服务器；
- 最后选择运行id小的从服务器
选举出新的主服务器后，sentinel会发送slaveof no one命令给被选中的服务器，然后每秒一次的频率发送INFO命令（平时是每10秒1次），观察新主服务器的role等信息，当被升级的服务器role由slave变成master时，则说明顺利升级了。
?9.2? 修改从服务器的复制目标
下一步，让已下线的主服务器从属的从服务器，全部改为复制新选出来的主服务器。通过发送slaveof 指令。?
下图展示了此时各个服务器的状态
9.3? 将旧的主服务器变为从服务器
最后一步，让已下线的主服务器上线后，改为新主服务器的从服务器。通过发送slaveof指令。
?