Redis Sentinel

一、简介:

         Sentinel（哨岗、哨兵）是Redis的高可用性（high availability）解决方案：由一个或多个Sentinel实例（instance）组成的Sentinel系统（system）可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。当主服务器下线时长超过用户设定的下线时长上限时，Sentinel系统就会对主服务器执行故障转移操作：将主服务器下的一个从服务器升级为主服务器，之后，Sentinel系统会向其他属从服务器发送新的复制指令，让它们成为新的主服务器的从服务器，当所有从服务器都开始复制新的主服务器时，故障转移操作执行完毕。另外，Sentinel还会继续监视已下线的server1，并在它重新上线时，将它设置为新的主服务器的从服务器。

二、组成:

         Redis Sentinel ，它由两部分组成，哨兵节点和数据节点：

• 哨兵节点： 哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据，对数据节点进行监控。
• 数据节点： 主节点和从节点都是数据节点；

         在复制的基础上，哨兵实现了 自动化的故障恢复 功能，下面是官方对于哨兵功能的描述：

• 监控（Monitoring）： 哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移（Automatic failover）： 当 主节点 不能正常工作时，哨兵会开始 自动故障转移操作，它会将失效主节点的其中一个 从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者（Configuration provider）： 客户端在初始化时，通过连接哨兵来获得当前 Redis 服务的主节点地址。
• 通知（Notification）： 哨兵可以将故障转移的结果发送给客户端。

         其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移。而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

三、实现原理:

         哨兵模式是通过哨兵节点完成对数据节点的监控、下线、故障转移。

• 定时监控

• Redis Sentinel通过三个定时监控任务完成对各个节点发现和监控：
1. 每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取服务器的最新的信息
2. 每隔2秒，每个Sentinel节点会向Redis数据节点（主服务器、从服务器）的__sentinel__：hello 频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息
3. 每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达、实例是否在线
• 主观下线和客观下线主观下线就是哨兵节点认为某个节点有问题，客观下线就是超过一定数量的哨兵节点认为主节点有问题。 

1. 主观下线 每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过 down-after-milliseconds（Sentinel配置文件中的down-after-milliseconds选项指定了Sentinel判断实例进入主观下线所需的时间长度。不仅会被Sentinel用来判断主服务器的主观下线状态，还会被用于判断主服务器属下的所有从服务器，以及所有同样监视这个主服务器的其他Sentinel的主观下线状态。对于监视同一个主服务器的多个Sentinel来说，所设置的世界长度也可能不同，因此当一个Sentinel讲主服务器判断为主观下线时，其他Sentinel可能仍然认为主服务器处于在线状态。）毫秒内没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线。

2. 客观下线 当Sentinel主观下线的节点是主节点（主服务器）时，为了确认该主服务器是否真的下线，该Sentinel节点会通过sentinel is- master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当从其他Sentinel接收到足够数量超过 <quorum>个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，并对主服务器执行故障转移操作。

• 领导者Sentinel节点选举Sentinel节点之间会做一个领导者选举的工作，选出一个Sentinel节点作为领导者进行故障转移的工作。Redis使用了Raft算法实现领导者选举。

• 故障转移

  领导者选举出的Sentinel节点负责故障转移，过程如下：

1. 在从节点列表中选出一个节点作为新的主节点，这一步是相对复杂一些的一步
2. Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点
3. Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点
4. Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点
5. 当新的主服务器出现后，让主服务器下的所有从服务器通过SLAVEOF命令来实现复制

四、领导者Sentinel节点选举:

         Redis使用了Raft算法实 现领导者选举，大致流程如下：

1. 每个在线的Sentinel节点都有资格成为领导者，每个发现主服务器进入客观下线的时候，都会向其他Sentinel节点发送sentinel is-master-down-by-addr命令， 要求将自己设置为局部领头Sentinel。
2. 收到命令的Sentinel节点，如果还没有设置局部领头Sentinel的话或者同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝。
3. 根据命令请求发送的先后顺序不同，可能会有某个Sentinel的SENTINEL is-master-down-by-addr命令比起其他Sentinel发送的相同命令都更快到达，并最终胜出局部领头Sentinel的选举（Sentinel设置局部领头Sentinel的规则是先到先得），该Sentinel节点发现自己的票数已经大于等于max（quorum， num（sentinels）/2+1），那么它将成为领导者。
4. 如果此过程没有选举出领导者，将进入下一次选举。

         新的主节点如何挑选？

         选出新的主节点，大概分为这么几步：

1. 过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel领头节点的info响应、与主节点失联超过down-after-milliseconds*10秒。
2. 选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续。
3. 选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，不存在则继续。
4. 选择runid最小的从节点。

五、Sentinel工作流程:

1. 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。
2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
3. 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4. 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。
5. 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。
6. 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。
7. 若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
8. 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
9. 当Sentinel集群客观的认为master宕机，就会从所有的Sentinel节点中，选出一个Sentinel节点，来最终执行master的故障转移。

        未经分析推算，下结论、决策和行为反应，暂时不能与其他不同看法的对象仔细商讨，称为主观。