在开发工作中，针对分布式缓存高可用方案（搭建Redis缓存高可用方案），Redis主从架构如何保证高可用？我们知道RedisSentinel是一个分布式系统，为Redis提供高可用的解决方案。Redis服务部署哨兵模式的主要原理是什么，解决了哪些问题，所以抽空整理了一下相关问题。相信看完这篇文章，你也可以和其他人分享技术。O(∩_∩)O哈哈~0。在讨论哨兵模式之前，我们先来看一个应用问题：Redis服务主机宕机。实际使用中，master可能宕机了（这会导致没有写服务，只有读服务）。如果我们要保证服务的可用性，就需要选择另外一个从节点作为主节点，继续提供服务能力。主要动作抽象为：让宕机的master下线找一个slave作为master通知所有slave连接新的master同步全部或部分数据有几个问题：谁来确认master宕机了？（如果只是网络抖动一点，会不会被关机？）如何从slave中找master，谁来找？如何找到它？依据是什么？修改配置后恢复原master怎么办？其实哨兵机制的引入可以很好的解决上面的问题。Sentinel-RedisCluster一、什么是Sentinel？哨兵（Sentinel）是Redis的一种高可用解决方案：一个由一个或多个哨兵实例组成的哨兵系统可以监控任意数量的主服务，以及这些主服务器下的所有从服务，当被监控的主服务进入离线状态(unserviceable)状态，自动将离线主服务器下的一个从服务器升级为新的主服务器。总结一下sentinel的作用：集群监控不断的检查master和slave是否正常运行（master存活检测，master和slave运行状态检测）消息通知当被监控的服务器出现问题时，向其他sentinel发送通知和clientstoautomaticallyfailtransfer断开失败的master和slave之间的连接，选择一个slave作为新的master，将其他slave连接到新的master并通知客户端新的服务器地址。注：Sentinel也是一个Redis服务器，但不提供数据服务；通常Sentinel配置的数量是奇数。2.Sentinel的工作原理下面主要介绍Sentinel在故障转移过程中经历的三个阶段。2.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等获取状态哨兵；哨兵之间会形成“对应通道”，大家发布信息、订阅信息、接收信息、同步信息等。2.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新的masterIP端口发送给其他slave。3、总结Redis主从复制的作用。可用性的基石”，哨兵和集群是实现高可用必不可少的。3.1哨兵的作用集群监控不断检查主从是否正常运行（主存检测、主从运行状态检测）消息通知当被监控时server有问题，会通知其他sentinel和clients自动failover并断开连接打开故障master和slave的连接，选择一个slave作为新的master，将其他slave连接到新的master上并通知client3.2Sentinel的工作原理每个Sentinel每秒向Master、Slave和其他它知道的Sentinel实例发送一次PING命令。如果一个实例（Instance）距离最后一次对PING命令的有效回复超过了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秒一次变为每秒一次。
