Redis Sentine高可用架构原理分析

1：sentinel中故障转移切换的流程
2：sentinel如何与master和slave通信。
3：如何发现故障。
4：选出领导者的流程。
5：主sentinel对新的主节点做了什么，还有从节点。

redis高可用的解决方案：Sentinel

redis sentinel是redis的高可用实现方案，sentinel节点是一个独立的sentinel进程。由之前介绍的主从复制，我们可以知道，如果主节点挂掉了，在没有任何外部工具的情况下，我们自己需要手动进行主从切换，在这个过程中，必然会丢掉部分数据，故障转移实时性和准确性都无法得到保障，所以，redis从2.8之后引入了redis setinel （哨兵）来解决这个问题。
redis sentinel 节点是一个独立的sentinel进程。而redis sentinel 是一个分布式架构，包含若干个sentinel节点和redis数据节点，客户端分布在多个物理机器节点的架构。redis sentinel的高可用性体现在，redis sentinel能够自动完成故障发现和故障转移。并通知应用方，从而实现真正的高可用。

Redis Sentinel功能：

监控：sentinel会定期检测主节点与副节点是否按照我们预期的工作。
通知：sentinel节点会将故障转移的结果通知给应用方。
自动故障转移：实现从节点晋升为主节点并维护后续正常的主从关系。
配置提供者：在redis sentinel结构中，客户端初始化的时候连接的是sentinel节点的集合，从中获取主节点信息。（开发redis客户端实现sentinel功能的基础）

redis各个功能探究以及功能补充

下图为实际演示的案例部署架构图：
sentinel节点的配置：
在这里是sentinel架构部署完成后，端口为26379的sentinel的配置文件，在这里配置文件去掉了
之前的parallel-syncs（新的主节点可以接收并发复制的个数）和failover-timeout两个参数配置。

sentinel monitor mymaster 127.0.0.1 7000 2
// 2--》quorum用于故障发现和判断，即客观下线的条件，将quorum设置为2，代表至少有2个sentinel节点认为主节点不可达，那么这个不可达判定才是客观的。改参数一般设置为sentinel节点的一半+1，

== 注意这里quorum参数还与sentinel节点的leader选举有关，至少要有max（quorum，（sentinel节点个数）/2+1）个sentinel节点参与投票，才可以选出sentinel leader进行故障转移。==

sentinel down-after-milliseconds
//每个sentinel节点都会定期（后面要讲的定期任务）发送ping命令来判断redis数据节点和其余sentinel节点是否可达，
如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达（主观判定）

failover-timeout通常被解释成故障转移超时时间，这个时间包含下面几个阶段
1：选出合适从节点
2：晋升选出的从节点为主节点
3：命令其他从节点复制新的主节点，遵循parallel-syncs原则
4：等待主节点回复后命令它去复制新的主节点

sentinel api：

sentinel api：列举重要的几个：
sentinel sentinels master name：展示master name的sentinel节点集合
sentinel get-master-addr-by-name mastername 返回指定master-name主节点的ip地址和端口
sentinel is-master-down-by-addr sentinel节点之间用于交换对主节点是否下线的判断。

通知：sentinel节点会将故障转移的结果通知给应用方。

实现原理：客户端为每一个sentinel节点单独启动一个线程，利用redis的发布订阅功能，每个线程订阅sentinel节点上切换master的相关频道：+switch-master

监控：sentinel会定期检测主节点与副节点是否按照我们预期的工作。

实现原理：
1:每隔10s，每个sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构，第一次获取主节点执行info命令，可以获取到从节点的ip。拿到从节点ip后可以递归继续执行info。
2：每隔2s，每个redis-sentinel节点都会向主redis数据节点的_sentinel_:hello频道上发送该sentinel节点对于主节点的判断以及当前sentinel节点的信息。同时每个sentinel节点也会订阅该频道，来了解其他sentinel节点以及它们对主节点的判断，所以这个定时任务有两个作用：
a：发现新的sentinel节点，订阅_sentinel_:hello了解其他的sentinel节点信息，如果是新加入的sentinel节点，将该sentinel节点保存起来，并与该sentiel节点建立连接。所以在任一sentinel节点上执行sentinel sentinels mastername都会获得主节点的全部sentinel节点信息。
b:sentinel节点之间交换主节点的状态，作为后面客观下线的依据。
3：每隔1s，每个sentinel节点都会向主节点，从节点，其余sentinel节点发送一条ping命令做心跳检测，来确认这些节点是否可达，这个定时任务是节点失败判定的重要依据。

主观下线与客观下线：

主观下线：上面所说每个Sentinel节点没隔1s都会对主节点，从节点，其他sentinel节点发送ping命令做心跳检测，这些节点超过down-after-milliseconds没有进行有效回复，sentinel节点就会对该节点做失败判定，这就是主观下线。

客观下线：当sentinel主观下线的节点是主节点时，该sentinel节点会通过sentinel is-master-down-by-addr命令向其他sentinel节点询问对主节点的判断，当超过quorum个数时，这时该sentinel节点会做出客观下线的决定。客观下线，即大部分sentinel节点都对主节点的下线做了同意的判定。
这里分析：
is-master-down-by-addr ip port current_epoch runid:
当runid等于时，作用是sentinel节点直接交换对主节点下线的判定。
当runid等于当前Sentinel节点的runid时，作用是当前sentinel节点希望目标sentinel节点同意自己成为领导者的请求。
执行此命令返回结果：
down state：目标sentinel节点对主节点状态的判断，1下线，0在线
leader_runid:当leader_runid等于“”时,代表返回结果用来做主节点是否不可达，当leader_runid等于具体的runid，代表目标节点同意runid成为领导者。
leader_epoch：领导者纪元。
领导者选出的从节点判断条件：
1：过滤掉在5s内没有回复过sentinel节点ping响应，与主节点失联超过down-after-milliseconds*10s的从节点。
2：选择slave-priority（从节点优先级最高的从节点）最大的从节点。
3：选择复制偏移量最大的从节点。
4 ：选择runid最小的节点，即最先启动的节点。

日志分析：故障转移

分析案例所用拓扑图在上面已经给出
1：手动对主节点执行kill -9 操作。
此时查看主节点的两个从节点 7001 7002 两个节点的日志，主节点被kill，没有变化，我们这里就不做讨论
7001.log
在10:13分与7000节点失联。
在10:14分收到sentinel节点命令，清理原来缓存主节点状态，sentinel节点将7001节点晋升为主节点，重写配置。
slave 7002发来复制请求，进行全量同步，开启rdb，进落盘，传输工作，最后成功结束。
观察7002节点日志：
10:14分收到sentinel节点命令，情路原来缓存的主节点状态，然后去复制新的主节点127.0.0.1 7001
然后建立连接，开启复制，最后复制成功。
观察sentinel节点（26379被选为领导者的节点日志）：

+sdown首先达到主观下线
+odown 然后达到客观下线，
+voted-for-leader：这个runid与26379的runid一样，此时该节点被选为leader。
voted for 收到来自其他两个sentinel节点的投票。
进行故障转移：
选择合适的从节点：
等待7001节点晋升为主节点:
确认7001节点晋升为主节点
故障转移进入重新分配从节点阶段
命令7002节点复制新的主节点
7002正在重新配置成为7001的从节点，但是同步尚未完成
7002节点完成对7001节点同步：
故障转移顺利完成
故障转移成功后，发布主节点切换信息：
最后发现了两个从节点，并对从节点（之前的主节点）做主观下线

观察26380端口的sentinel节点的日志信息：
只进行了主观判断，然后给26379端口的sentinel投票。
从26379sentinel节点得到通知，故障转以后主节点变为7001
并发现了两个从节点，并对从节点（之前的主节点）做主观下线
26381因为不是leader所以日志与26380一样，不做分析，当7000重新恢复连接后，会去复制7001节点。