Redis哨兵模式原理

哨兵模式

哨兵(sentinel) 是一个分布式系统,可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.
　　每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
　　若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.
　　虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨(sentinel).哨兵(sentinel) 的一些设计思路和zookeeper非常类似

实现原理

三个定时监控任务

1. 每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取Redis数据节点的信息。

作用：

• 通过向主节点执行info命令，获取从节点的信息，这也是为什么Sentinel节点不需要显式配置监控从节点。
• 当有新的从节点加入时都可以立刻感知出来。
• 节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信息。

分析
　　Sentinel以每10秒一次的频率向master发送info命令，通过info的回复来分析master信息，master的回复主要包含了两部分信息，一部分是master自身的信息，一部分是master所有的slave（从）的信息，所以sentinel可以自动发现master的从服务。sentinel从master哪儿获取到的master自身信息以及master所有的从信息，将会更新到sentinel的sentinelState中及masters（sentinelRedisInstance结构）中的slaves字典中
　　

２．每隔2秒，每个Sentinel节点会向Redis数据节点的__sentinel__：hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他
Sentinel节点以及它们对主节点的判断。

消息格式：
<Sentinel节点IP> <Sentinel节点端口> <Sentinel节点runId> <Sentinel节点配置纪元>
<主节点名字> <主节点Ip> <主节点端口> <主节点配置纪元>
各个参数的解析如下

    s_ip：sentinel的ip

    s_port：sentinel的端口

    s_runid：sentinel云心id

    s_epoch：sentinel当前的配置纪元

    m_name：主服务器名字

    m_ip：主服务器ip

    m_port：主服务器端口

    m_epoch：主服务器纪元

作用：

• 发现新的Sentinel节点：通过订阅主节点的__sentinel__：hello了解其他的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保存起来（如下图：sentinelRedisInstance），并与该Sentinel节点创建连接。
• Sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选举的依据。
  

3. 每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达

主观下线和客观下线

主观下线：
　　所谓主观下线，就是单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。
　　sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，通过判断ping回复是有效回复，还是无效回复来判断实例时候在线（对该sentinel来说是“主观在线”）
　　 sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel会认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。在实际的工作当中，多个sentinel配置的down-after-milliseconds　超时时间推荐一致。
　　
客观下线：
　　客观下线 只针对 主节点，从节点和哨兵节点不需要这一步
　　当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel ismaster-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过配置中的< quorum >个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，并后续对其做故障转移操作。
　　如果每个Sentinel　配置的down-after-milliseconds时间不一致，会很难超过< quorum >配置的个数
　　sentinel is-master-down-by-addr < ip > < por t> < current_epoch > < runid >
例如：sentinel is-master-down-by-addr 127.0.0.1 6379 0 *

• ip：主节点IP。
• port：主节点端口。
• current_epoch：当前配置纪元。
• runid：此参数有两种类型，当runid等于“*”时，作用是Sentinel节点直接交换对主节点下线的判定。在领导者Sentinel节点选举时，runid等于当前Sentinel节点的runid，作用是当前Sentinel节点希望目标Sentinel节点同意自己成为领导者的请求。

一个sentinel接收另一个sentinel发来的is-master-down-by-addr后，提取参数，根据ip和端口，检测该服务时候在该sentinel主观下线，并且回复is-master-down-by-addr

• down_state：目标Sentinel节点对于主节点的下线判断，1是下线，0是在线。
• leader_runid：当leader_runid等于“*”时，代表返回结果是用来做主节点是否不可达，当leader_runid等于具体的runid，代表目标节点同意runid成为领导者。
• leader_epoch：领导者纪元。

领导者Sentinel节点选举

Redis使用了Raft算法实现领导者选举，大体思路：

1. 每个在线的Sentinel节点都有资格成为领导者，每个Sentinel节点发现当它确认主节点客观下线检查时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者。
2. 每个节点在每个选举轮次中只有一次投票权，收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinelis-master-down-by-addr命令，将同意该请求，否则拒绝。
3. 如果该Sentinel节点发现自己的票数已经大于等于max（quorum，num（sentinels）/2+1），那么它将成为领导者。其他的投票就会终止，即使后续还有其他的哨兵节点到达配置，也没有作用
4. 如果此过程没有选举出领导者， 暂定一段时间，再进行下一轮选举，current_epoch加1。

图例：

s1(哨兵节点)节点首先完成客观下线的检查，然后向s2和s3发送成为领导者的请求：

s2节点完成客观下线的检查，然后向s1和s3发送成为领导者的请求：

s３节点完成客观下线的检查，然后向s１和s２发送成为领导者的请求：

故障转移

故障转移分为四个主要步骤

a、 在从节点列表中选出一个作为新的主节点

[1] 　过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节点ping响应、与主节点失联超过down-after-milliseconds*10秒。（断线时间越长主从数据不一致问题越严重）

[2] 　选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续。

[3] 　如果优先级一样，选择复制偏移量最大的从节点（复制的最完整，尽可能的减少数据丢失），如果存在则返回，不存在则继续。

[4] 　如果偏移量一样，选择runid最小的从节点。

挑选从节点的重要原则：在从从节点列表中挑选与主节点数据最一致的节点。

b、 Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。

c、 Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和parallel-syncs参数有关。slaveof ip port

d、 Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点。

Sentinel命令

1、 sentinel masters
展示所有被监控的主节点状态以及相关的统计信息

2、 sentinel master<master name>
       展示指定<master name>的主节点状态以及相关的统计信息

3、 sentinel slaves<master name>
展示指定<master name>的从节点状态以及相关的统计信息

4、 sentinel sentinels<master name>
展示指定<master name>的Sentinel节点集合（不包含当前Sentinel节点）。

5、 sentinel get-master-addr-by-name<master name>
返回指定<master name>主节点的IP地址和端口

6、 sentinel failover<master name>
对指定<master name>主节点进行强制故障转移

7、 sentinel ckquorum<master name>
检测当前可达的Sentinel节点总数是否达到<quorum>的个数

8、 sentinel remove<master name>
取消当前Sentinel节点对于指定<master name>主节点的监控。

9、 sentinel monitor<master name><ip><port><quorum>
通过命令的形式来完成Sentinel节点对主节点的监控。

10、 sentinel set<master name>
动态修改Sentinel节点配置选项，这个命令已经在9.2.4小节进行了说明

11、 sentinel is-master-down-by-addr
Sentinel节点之间用来交换对主节点是否下线的判断，根据参数的不同，还可以作为Sentinel领导者选举的通信方式