开发工作中对于分布式缓存高可用方案（搭建Redis缓存高可用方案），Redis主从架构下是如何保证高可用的呢？
我们知道是应用了哨兵机制来实现。那Redis 服务部署的哨兵模式主要是什么，又解决了什么问题呢，于是利用周末时间整理了下，相信看完这篇文章，你也可以去给别人做技术分享了。O(∩_∩)O哈哈~
问题铺垫
在讨论哨兵模式之前，我们先来看一个应用问题：Redis服务主机宕机
实际使用过程中，会出现master宕机的情况（这样会导致没有写服务，只有读服务）。
那我们要保证服务的可用，就需要从其他salve节点中选取一个来作为master节点，来继续提供服务能力。
那主要的动作抽象下：
- 将宕机的master下线
- 找一个slave作为master
- 通知所有的slave连接新的master
- 全量数据或者部分数据同步
其中存在几个问题：
- 谁来确认master宕机？（假如仅仅是网络抖动了一下，就把我宕掉么？）
- 如何从slave中找一个master代替，谁来找？怎么找？有什么依据？
- 修改配置后，原始的主恢复了怎么办？
其实引入哨兵机制，就可以很好的解决上述问题。
哨兵-Redis集群
什么是哨兵？
Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例组成的Sentinel 系统可以监视任意多个主服务，以及这些主服务器属下的所有从服务，并在被监视的主服务进入下线（不可服务）状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。
总结一下哨兵的作用：
集群监控
不断的检查master和slave是否正常运行（master存活检测、master与slave运行情况检测）
- 消息通知
当被监控的服务器出现问题时，向其他哨兵、客户端发送通知
- 自动故障转移
断开故障master与slave的连接，选取一个slave作为新master，将其他slave连接到新的master并告知客户端新的服务器地址。
注意：哨兵也是一台Redis服务器，只是不提供数据服务；通常哨兵配置的数量为单数。
哨兵的工作原理
下面主要针对哨兵在进行故障转移过程中经历的三个阶段分别进行阐述。
1、集群监控
step1：哨兵1连接到Redis集群
- 发送info命令到master，并建立cmd连接；
- 哨兵端保存哨兵状态（SentinelStatus），保存所有哨兵状态，主节点和从节点的信息；master端会记录 redis 实例的信息（SentinelRedisInstance）；
- 哨兵根据master中获取的每个slave信息，去连接每个slave，发送同样也是info命令。
集群监控
step2：哨兵2加入进来后
- 同样会发送info命令到master节点，并建立cmd连接；
- 发现master中存在其他哨兵节点的信息，哨兵2中保存哨兵信息（区别与哨兵1的是它保存了哨兵1和哨兵2的2个哨兵节点信息）；
- 为了每个哨兵的信息都一致它们之间建立了一个发布订阅。为了哨兵之间的信息长期对称它们之间也会互发 ping 命令。
集群监控
step3：哨兵3加入后
- 同样进行哨兵1、2的动作，会发送info命令到master节点，并建立cmd连接；
- 为了保证哨兵1-哨兵2之间的信息是同步的，建立了一个发布订阅的一个队列（可以互发ping命令）
集群监控
小结一下：
- Sentinel会向master、slave以及其他Sentinel获取状态；
- Sentinel之间会组建“对应频道”，大家一起发布信息、订阅信息、收信息、同步信息等。
2、消息通知
1）Sentinel节点会通过master/slave 节点建立的cmd连接获取其工作状态
2）Sentinel收到反馈结果之后，会在哨兵内部进行信息的互通
消息通知
3、故障转移
关于故障转移，严格来讲可划分两个步骤：故障判定、故障转移。
Q1：如何判断一个节点出现故障？
- 哨兵会一直给主节点发送 publish sentinel：hello
直到主节点故障，哨兵报出 sdown，同时此哨兵还会向其他哨兵发布消息说这个主节点挂了。发送的指令是 sentinel is-master-down-by-address-port。
- 其余的哨兵接收到指令后，主节点挂了吗？让我去看看到底挂没挂。发送的信息也是 hello。
其余的哨兵也会发送他们收到的信息并且发送指令 sentinel is-master-down-by-address-port 到自己的内网，确认一下第一个发送 sentinel is-master-down-by-address-port 的哨兵说你说的对，这个家伙确实挂了。
- 当所有人都认为主节点挂了后就会修改其状态为 odown。
当一个哨兵认为主节点挂了标记的是 sdown，当半数哨兵都认为挂了其标记的状态是 odown。
一个哨兵认为master节点挂了称为主观下线（sdown），超半数哨兵认为master节点挂了则称为客观下线（odown）。
Q2：如何进行故障转移？
1）首先，哨兵选举出哨兵Leader去处理故障转移
此时选举方式应用的是Raft协议，这个之前有过介绍，感兴趣的同学可以移步了解：一致性算法Raft 简易入门
2）其次，哨兵Leader从所有的slave节点找出一个作为master节点
主要的规则：
- 选择在线的节点，pass掉已下线的节点；
- 选择响应速度快的，pass掉响应慢的节点
- 选择与原master断开时间短的，pass掉断开时间较长的；
假如以上优先级均一致，会考虑其他优先原则：
- 偏移量较大
假如说 slave1 的 offset 为 50，slave2 偏移量为 55，则哨兵就会选择 slave2 为新的主节点。
- runid偏大的
这点类似于职场中的论资排辈，也就说根据 runid 的创建时间来判断，时间早的先上位。
3）数据转移
- 新master上任：Sentinel向新的master发送slaveof no one
- 其他slave周知：向其他slave发送slaveof 新master IP端口
总结
Redis 主从复制的作用中有这么一句话“主从复制是高可用的基石”，那实现高可用必不可少的就是哨兵和集群。
1、Sentinel的作用
- 集群监控
不断的检查master和slave是否正常运行（master存活检测、master与slave运行情况检测）
- 消息通知
当被监控的服务器出现问题时，向其他哨兵、客户端发送通知
- 自动故障转移
断开故障master与slave的连接，选取一个slave作为新master，将其他slave连接到新的master并告知客户端新的服务器地址。
2、Sentinel的工作方式
- 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
- 如果一个实例（Instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
- 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
- 当有足够数量的 Sentinel（>=配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线
若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
- 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令
- 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
