Redis哨兵机制详解哨兵机制Redis SentinelRedis Sentinel即Redis哨兵在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。下图是一个典型的哨兵集群监控的逻辑图哨兵实现了什么功能呢下面是Redis官方文档的描述监控Monitoring哨兵会不断地检查主节点和从节点是否运作正常。自动故障转移Automatic failover当主节点不能正常工作时哨兵会开始自动故障转移操作它会将失效主节点的其中一个从节点升级为新的主节点并让其他从节点改为复制新的主节点。配置提供者Configuration provider客户端在初始化时通过连接哨兵来获得当前Redis服务的主节点地址。通知Notification哨兵可以将故障转移的结果发送给客户端。其中监控和自动故障转移功能使得哨兵可以及时发现主节点故障并完成转移而配置提供者和通知功能则需要在与客户端的交互中才能体现。哨兵集群的组建上图中哨兵集群是如何组件的呢哨兵实例之间可以相互发现要归功于 Redis 提供的 pub/sub 机制也就是发布 / 订阅机制。在主从集群中主库上有一个名为__sentinel__:hello的频道不同哨兵就是通过它来相互发现实现互相通信的。在下图中哨兵 1 把自己的 IP172.16.19.3和端口26579发布到__sentinel__:hello频道上哨兵 2 和 3 订阅了该频道。那么此时哨兵 2 和 3 就可以从这个频道直接获取哨兵 1 的 IP 地址和端口号。然后哨兵 2、3 可以和哨兵 1 建立网络连接。通过这个方式哨兵 2 和 3 也可以建立网络连接这样一来哨兵集群就形成了。它们相互间可以通过网络连接进行通信比如说对主库有没有下线这件事儿进行判断和协商。哨兵监控Redis库哨兵监控什么呢怎么监控呢这是由哨兵向主库发送 INFO 命令来完成的。就像下图所示哨兵 2 给主库发送 INFO 命令主库接受到这个命令后就会把从库列表返回给哨兵。接着哨兵就可以根据从库列表中的连接信息和每个从库建立连接并在这个连接上持续地对从库进行监控。哨兵 1 和 3 可以通过相同的方法和从库建立连接。主库下线的判定哨兵如何判断主库已经下线了呢首先要理解两个概念主观下线和客观下线主观下线任何一个哨兵都是可以监控探测并作出Redis节点下线的判断客观下线有哨兵集群共同决定Redis节点是否下线当某个哨兵如下图中的哨兵2判断主库“主观下线”后就会给其他哨兵发送is-master-down-by-addr命令。接着其他哨兵会根据自己和主库的连接情况做出 Y 或 N 的响应Y 相当于赞成票N 相当于反对票。如果赞成票数这里是2是大于等于哨兵配置文件中的quorum配置项比如这里如果是quorum2, 则可以判定主库客观下线了。哨兵集群的选举判断完主库下线后由哪个哨兵节点来执行主从切换呢这里就需要哨兵集群的选举机制了。为什么必然会出现选举/共识机制为了避免哨兵的单点情况发生所以需要一个哨兵的分布式集群。作为分布式集群必然涉及共识问题即选举问题同时故障的转移和通知都只需要一个主的哨兵节点就可以了。哨兵的选举机制是什么样的哨兵的选举机制其实很简单就是一个Raft选举算法选举的票数大于等于num(sentinels)/21时将成为领导者如果没有超过继续选举Raft算法你可以参看这篇文章分布式算法 - Raft算法任何一个想成为 Leader 的哨兵要满足两个条件第一拿到半数以上的赞成票第二拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。以 3 个哨兵为例假设此时的 quorum 设置为 2那么任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票就可以了。更进一步理解这里很多人会搞混判定客观下线和是否能够主从切换用到选举机制两个概念我们再看一个例子。Redis 1主4从5个哨兵哨兵配置quorum为2如果3个哨兵故障当主库宕机时哨兵能否判断主库“客观下线”能否自动切换经过实际测试1、哨兵集群可以判定主库“主观下线”。由于quorum2所以当一个哨兵判断主库“主观下线”后询问另外一个哨兵后也会得到同样的结果2个哨兵都判定“主观下线”达到了quorum的值因此哨兵集群可以判定主库为“客观下线”。2、但哨兵不能完成主从切换。哨兵标记主库“客观下线后”在选举“哨兵领导者”时一个哨兵必须拿到超过多数的选票(5/213票)。但目前只有2个哨兵活着无论怎么投票一个哨兵最多只能拿到2票永远无法达到N/21选票的结果。新主库的选出主库既然判定客观下线了那么如何从剩余的从库中选择一个新的主库呢过滤掉不健康的下线或断线没有回复过哨兵ping响应的从节点选择salve-priority从节点优先级最高redis.conf的选择复制偏移量最大只复制最完整的从节点