开发工做中对于分布式缓存高可用方案（搭建Redis缓存高可用方案），Redis主从架构下是如何保证高可用的呢？redis
咱们知道是应用了哨兵机制来实现。那Redis 服务部署的哨兵模式主要是什么，又解决了什么问题呢，因而利用周末时间整理了下，相信看完这篇文章，你也能够去给别人作技术分享了。O(∩_∩)O哈哈~算法
问题铺垫
在讨论哨兵模式以前，咱们先来看一个应用问题：Redis服务主机宕机缓存
实际使用过程当中，会出现master宕机的状况（这样会致使没有写服务，只有读服务）。那咱们要保证服务的可用，就须要从其余salve节点中选取一个来做为master节点，来继续提供服务能力。服务器
那主要的动做抽象下：微信
-
将宕机的master下线网络
-
找一个slave做为master架构
-
通知全部的slave链接新的master分布式
-
全量数据或者部分数据同步spa
其中存在几个问题：.net
-
谁来确认master宕机？（假如仅仅是网络抖动了一下，就把我宕掉么？）
-
如何从slave中找一个master代替，谁来找？怎么找？有什么依据？
-
修改配置后，原始的主恢复了怎么办？
其实引入哨兵机制，就能够很好的解决上述问题。
哨兵-Redis集群
什么是哨兵？
Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例组成的Sentinel 系统能够监视任意多个主服务，以及这些主服务器属下的全部从服务，并在被监视的主服务进入下线（不可服务）状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。
总结一下哨兵的做用：
-
集群监控
不断的检查master和slave是否正常运行（master存活检测、master与slave运行状况检测）
-
消息通知
当被监控的服务器出现问题时，向其余哨兵、客户端发送通知
-
自动故障转移
断开故障master与slave的链接，选取一个slave做为新master，将其余slave链接到新的master并告知客户端新的服务器地址。
注意：哨兵也是一台Redis服务器，只是不提供数据服务；一般哨兵配置的数量为单数。
哨兵的工做原理
下面主要针对哨兵在进行故障转移过程当中经历的三个阶段分别进行阐述。
一、集群监控
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加入后
-
一样进行哨兵一、2的动做，会发送info命令到master节点，并创建cmd链接；
-
为了保证哨兵1-哨兵2之间的信息是同步的，创建了一个发布订阅的一个队列（能够互发ping命令）
集群监控
小结一下：
-
Sentinel会向master、slave以及其余Sentinel获取状态；
-
Sentinel之间会组建“对应频道”，你们一块儿发布信息、订阅信息、收信息、同步信息等。
二、消息通知
1）Sentinel节点会经过master/slave 节点创建的cmd链接获取其工做状态
2）Sentinel收到反馈结果以后，会在哨兵内部进行信息的互通
消息通知
三、故障转移
关于故障转移，严格来说可划分两个步骤：故障断定、故障转移。
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 主从复制的做用中有这么一句话“主从复制是高可用的基石”，那实现高可用必不可少的就是哨兵和集群。
一、Sentinel的做用
-
集群监控
不断的检查master和slave是否正常运行（master存活检测、master与slave运行状况检测）
-
消息通知
当被监控的服务器出现问题时，向其余哨兵、客户端发送通知
-
自动故障转移
断开故障master与slave的链接，选取一个slave做为新master，将其余slave链接到新的master并告知客户端新的服务器地址。
二、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 秒一次改成每秒一次
往期热文推荐：
「技术架构精进」专一架构研究，技术分享
Thanks for reading!
本文分享自微信公众号 - 架构精进之路（jiagou_jingjin）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。