在开发工作中，对于分布式缓存高可用方案（搭建Redis缓存高可用方案），Redis主从架构是如何保证高可用的？我们知道是应用哨兵机制来实现的。那么Redis服务部署的主要哨兵模式是什么，解决了哪些问题，于是利用周末的时间整理了一下。相信看完这篇文章，你也可以和其他人分享技术。O(∩_∩)呵呵~问题铺垫在讨论sentinel模式之前，先来看一个应用问题：Redis服务主机宕机在实际使用过程中，会出现master宕机（这会导致没有写服务，只有读服务).如果我们要保证服务的可用性，就需要选择另外一个从节点作为主节点，继续提供服务能力。主要动作抽象为：让宕机的master下线找一个slave作为master通知所有slave连接新的master同步全部或部分数据有几个问题：谁来确认master宕机了？（如果只是网络抖动一点，会不会被关机？）如何从slave中找master，谁来找？如何找到它？依据是什么？修改配置后恢复原master怎么办？其实哨兵机制的引入可以很好的解决上面的问题。Sentinel-Redis集群什么是Sentinel？哨兵（Sentinel）是Redis的一种高可用解决方案：一个由一个或多个哨兵实例组成的哨兵系统可以监控任意数量的主服务，以及这些主服务器下的所有从服务，当被监控的主服务进入离线状态(unserviceable)状态，自动将离线主服务器下的一个从服务器升级为新的主服务器。总结一下sentinel的作用：集群监控不断的检查master和slave是否正常运行（master存活检测，master和slave运行状态检测）消息通知当被监控的服务器出现问题时，向其他sentinel发送通知和clientstoautomaticallyfailtransfer断开失败的master和slave之间的连接，选择一个slave作为新的master，将其他slave连接到新的master并通知客户端新的服务器地址。注：Sentinel也是一个Redis服务器，但不提供数据服务；通常Sentinel配置的数量是奇数。下面主要针对Sentinel在故障转移过程中所经历的三个阶段来介绍Sentinel的工作原理。1、集群监控step1：Sentinel1连接Redis集群向master发送info命令，建立cmd连接；哨兵端保存哨兵状态（SentinelStatus），保存所有哨兵状态，主从节点信息；master端会记录redisInstance信息（SentinelRedisInstance）；Sentinel根据从master获得的各个slave信息连接到各个slave，发送相同的info命令。集群监控step2：Sentinel2加入后，也会向master节点发送info命令，建立cmd连接；发现master中有其他sentinel节点的信息，Sentinel2保存了Sentinel信息（与Sentinel1的区别是保存了Sentinel1和Sentinel2的Sentinel2Sentinel节点信息）；为了让每个Sentinel的信息保持一致，它们之间建立了一个发布-订阅。为了Sentinels之间的信息长期对称，它们也会互相发送ping命令。集群监控step3：Sentinel3加入后，也会执行Sentinel1和2的动作，会向master节点发送info命令，建立cmd连接；为了保证Sentinel1和Sentinel2之间的信息同步，建立了一个publishsubscription队列（可以互相发送ping命令）集群监控总结：Sentinel会从master、slave等其他Sentinels获取状态；Sentinels之间会建立“对应通道”，大家一起发布信息、订阅信息、接收信息、同步信息等等。2.消息通知1)Sentinel节点会通过主/从节点建立的cmd连接获取自己的工作状态2)Sentinel收到反馈结果后，会在Sentinel内部进行信息通信一般来说，可以分为两种步骤：故障判定和故障转移。Q1：如何判断节点失效？哨兵会一直向主节点发送publishsentinel:hello，直到主节点出现故障，哨兵报告sdown。同时哨兵也会向其他哨兵发出消息，说主节点宕机了。发送的命令是sentinelis-master-down-by-address-port。其他哨兵收到命令后主节点挂了？让我看看它是否起来了。发来的信息也是你好。其余的哨兵也会把收到的信息发送给自己的内网命令sentinelis-master-down-by-address-port，确认第一个发送的sentinelis-master-down-by-address-port哨兵说你是对的，那家伙确实挂了。当大家认为主节点宕机时，就会修改自己的状态为odown。当一个sentinel认为master节点挂了flag就sdown了，当一半的sentinel认为flag挂了就odown了。如果一个sentinel认为master节点挂了，就叫主观下线（sdown），如果超过半数的哨兵认为master节点挂了，就叫客观下线（odown）。Q2：如何进行故障转移？1）首先，Sentinel选出一个SentinelLeader来处理failover。此时选举方式使用Raft协议。这个之前介绍过。有兴趣的同学可以移步学习：共识算法Raft简单介绍2）二、SentinelLeader从所有从节点中找出一个主规则作为主节点：选择在线节点，通过离线节点；选择响应速度快的节点，通过响应慢的节点，选择与原master断开连接时间短的节点，通过断开时间较长的节点；如果以上优先级一致，会考虑其他优先级原则：较大的offset如果slave1的offset为50，slave2的offset为55，sentinel会选择slave2作为新的master节点。runid过大类似于职场中的资历排序，也就是说从runid的创建时间来看，时间越早的越靠前。3）数据传输新master上任：sentinel发送slaveofnoone给新master其他slave众所周知：发送slaveof给其他slave新masterIP端口总结Redis主从复制的作用有这么一句话“master-从复制是高可用的基石”，哨兵和集群是实现高可用必不可少的。1.SentinelCluster监控的作用不断检查master和slave是否正常运行（master存活检测，master和slave运行检测）消息通知当被监控的服务器出现问题时，会自动发送通知给其他sentinel和clientfailover断开故障主机与从机的连接，选择一个从机作为新的主机，将其他从机连接到新的主机，并通知客户端新的服务器地址。2.Sentinel的工作方式每个Sentinel每秒向Master、Slave和其他它认识的Sentinel实例发送一次PING命令。如果一个实例（Instance）超过down-After-milliseconds选项指定的值，这个实例将被Sentinel标记为主观下线。如果Master再次对Sentinel的PING命令返回有效回复，Master的主观离线状态将被解除。如果一个Master被标记为主观下线，则所有监控该Master的Sentinel必须每秒确认一次该Master确实进入了主观下线状态。当足够数量的Sentinels（>=配置文件中指定的值）确认Master在指定的时间范围内确实进入了主观下线状态时，Master会被标记为客观下线。如果没有足够多的Sentinels同意Master已经下线，Master的客观下线状态将被移除。正常情况下，每个Sentinel每隔10秒会向它认识的所有Master和Slave发送一次INFO命令。当Master被Sentinel标记为客观下线时，Sentinel会向下线Master的所有Slave发送INFO。命令频率从每10秒一次更改为每秒一次
