Redis(六）--高可用哨兵机制

哨兵机制（Redis Sentinel）

在Redis主从集群中，哨兵机制是实现主从库自动切换的换件机制，它有效的解决了主从复制模式下故障转移的问题。哨兵的核心功能是主节点的自动故障转移。

哨兵的作用

• 监控：哨兵会不断的检查主节点和从节点是否运作正常。
• 自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，他会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
• 通知：哨兵可以将故障转移的结果发送给客户端。

监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

哨兵集群的组建

哨兵实例之间可以相互发现，要归功于Redis提供的pub/sub机制。
在主从集群中，主库上有一个名为__sentinel__:hello的频道，不同哨兵就是通过他来相互发现，实现互相通信的。

哨兵1把自己的IP和端口发布到__sentinel__:hello频道上，哨兵2和3订阅了该频道。那么此时，哨兵2和3就可以从这个频道直接获取哨兵1的IP地址和端口号。哨兵2和3就可以从这个频道直接获取哨兵1的IP地址和端口号。然后，哨兵2和3可以和哨兵1建立网络连接。通过这个方式，哨兵2和3也可以建立网络连接，这样一来，哨兵集群就形成了，他们相互间可以通过网络连接进行通信，比如说对主库有没有下线这件事儿进行判断和协商。

哨兵监控Redis库

是由哨兵向主库发送INFO命令来完成的。

哨兵2给主库发送INFO命令，主库接受这个命令后，就会把从库列表返回给哨兵。接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续的对库进行监控。哨兵1和3可以通过相同的方法和从库建立连接。

主库下线的判定

• 主观下线：任何一个哨兵都是可以监控探测，并作出Redis节点下线的判断
• 客观下线：有哨兵群共同决定Redis节点是否下线；
  当某个哨兵判断主库“主观下线”之后，就会给其他哨兵发送is-master-down-by-addr命令。接着，其他哨兵会根据自己和主库的连接情况，做出Y或者N的响应，Y相当于赞成票，N相当于反对票。如果赞成票数是大于等于哨兵配置文件中的quorum配置项，则可以判断主库客观下线了。
  

哨兵集群的选举

哨兵集群的选举机制用来实现判断完主库下线后，选择哪个哨兵节点来执行主从切换。

为什么会必然会出现选举/共识机制？
为了避免哨兵的单点情况的发生，所以需要一个哨兵的分布式集群。作为分布式集群，必然涉及共识问题（即选举问题），同时故障的转移和通知都只需要一个主的哨兵节点就可以了。
哨兵的选举机制是什么样的？
就是一个Raft算法：选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，则继续选举。
任何一个想成为Leader的哨兵，要满足两个条件：

1. 拿到半数以上的赞成票
2. 拿到的票数同时还需要大于等于哨兵配置文件中的quorum值。

这里需要注意：判定客观下线和是否能够主从切换（用到选举机制）是两个概念。

新主库的选出

• 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点。
• 选择salve-priority从节点优先级最高（redis.conf）的
• 选择复制偏移量最大，指复制最完成的从节点
  

故障的转移

假设判断主库下线了，同时选出sentinel 3是哨兵leader。

故障转移流程如下：

转移之后：

感谢并参考：
https://pdai.tech/md/db/nosql-redis/db-redis-x-sentinel.html
https://time.geekbang.org/column/article/275337
https://time.geekbang.org/column/article/274483
https://www.cnblogs.com/andy6/p/10829929.html