Redis哨兵模式

主库挂了如何处理？
redis通过哨兵模式进行主从库切换，哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。

监控是指哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行。如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；同样，如果主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，然后开始自动切换主库的流程。为了避免集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下造成的单结点哨兵误判，所以采集哨兵集群模式进行判断。

选主
多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库。
网络判定：
通过该配置项 down-after-milliseconds * 10。其中，down-aftermilliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-aftermilliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。

从库打分的条件：从库优先级、从库复制进度以及从库 ID 号
第一轮：优先级最高的从库得分高。用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级。比如，有两个从库，它们的内存大小不一样，你可以手动给内存大的实例设置一个高优先级。在选主时，哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。

第二轮：和旧主库同步程度最接近的从库得分高。
这个规则的依据是，如果选择和旧主库同步最接近的那个从库作为主库，那么，这个新主库上就有最新的数据。如何判断从库和旧主库间的同步进度呢？
主从库同步时有个命令传播的过程中，主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置，而从库会用 slave_repl_offset 这个值记录当前的复制进度。此时，我们想要找的从库，它的 slave_repl_offset 需要最接近master_repl_offset。如果在所有从库中，有从库的 slave_repl_offset 最接近master_repl_offset，那么它的得分就最高，可以作为新主库。

第三轮：ID 号小的从库得分高
每个实例都会有一个 ID，这个 ID 就类似于这里的从库的编号。目前，Redis 在选主库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。

哨兵在操作主从切换的过程中，客户端能否正常地进行请求操作？
如果客户端使用了读写分离，那么读请求可以在从库上正常执行，不会受到影响。但是由于此时主库已经挂了，而且哨兵还没有选出新的主库，所以在这期间写请求会失败，失败持续的时间 = 哨兵切换主从的时间 + 客户端感知到新主库 的时间。如果不想让业务感知到异常，客户端只能把写失败的请求先缓存起来或写入消息队列中间件中，等哨兵切换完主从后，再把这些写请求发给新的主库，但这种场景只适合对写入请求返回值不敏感的业务，而且还需要业务层做适配，另外主从切换时间过长，也会导致客户端或消息队列中间件缓存写请求过多，切换完成之后重放这些请求的时间变长。

哨兵检测主库多久没有响应就提升从库为新的主库，这个时间是可以配置的（down-aftermilliseconds参数）。配置的时间越短，哨兵越敏感，哨兵集群认为主库在短时间内连不上就会发起主从切换，这种配置很可能因为网络拥塞但主库正常而发生不必要的切换，当然，当主库真正故障时，因为切换得及时，对业务的影响最小。如果配置的时间比较长，哨兵越保守，这种情况可以减少哨兵误判的概率，但是主库故障发生时，业务写失败的时间也会比较久，缓存写请求数据量越多。

通知
应用程序不感知服务的中断，还需要哨兵和客户端做些什么？
当哨兵完成主从切换后，客户端需要及时感知到主库发生了变更，然后把缓存的写请求写入到新库中，保证后续写请求不会再受到影响，具体做法如下：
A、 哨兵提升一个从库为新主库后，哨兵会把新主库的地址写入自己实例的pubsub（switchmaster）中。客户端需要订阅这个pubsub，当这个pubsub有数据时，客户端就能感知到主库发生变更，同时可以拿到最新的主库地址，然后把写请求写到这个新主库即可，这种机制属于哨兵主动通知客户端。
B、 如果客户端因为某些原因错过了哨兵的通知，或者哨兵通知后客户端处理失败了，安全起见，客户端也需要支持主动去获取最新主从的地址进行访问。所以，客户端需要访问主从库时，不能直接写死主从库的地址了，而是需要从哨兵集群中获取最新的地址（sentinel get-master-addr-by-name命令），这样当实例异常时，哨兵切换后或者客户端断开重连，都可以从哨兵集群中拿到最新的实例地址。
C、分片集群模式下，这些逻辑都可以做在proxy层，这样客户端也不需要关心这些逻辑了。

哨兵集群中有实例挂了，怎么办，会影响主库状态判断和选主吗？
存在故障节点时，只要集群中大多数节点状态正常，集群依旧可以对外提供服务

哨兵集群多数实例达成共识，判断出主库“客观下线”后，由哪个实例来执行主从切换呢？
哨兵集群判断出主库“主观下线”后，会选出一个“哨兵领导者”，之后整个过程由它来完成主从切换。但是如何选出“哨兵领导者”？这个问题也是一个分布式系统中的问题，就是我们经常听说的共识算法，指的是集群中多个节点如何就一个问题达成共识。共识算法有很多种，例如Paxos、Raft，这里哨兵集群采用的类似于Raft的共识算法。简单来说就是每个哨兵设置一个随机超时时间，超时后每个哨兵会请求其他哨兵为自己投票，其他哨兵节点对收到的第一个请求进行投票确认，一轮投票下来后，首先达到多数选票的哨兵节点成为“哨兵领导者”，如果没有达到多数选票的哨兵节点，那么会重新选举，直到能够成功选出“哨兵领导者”。
哨兵成为Leader的必要条件:
1、获得半数以上的票数。
2、得到的票数要达到配置的quorum阀值。

总结 ：
1.哨兵之间的互动是通过发布订阅机制完成的，利用自身的特性来实现。
2.哨兵之间通信不是哨兵之间联系，而是通过订阅主库的同一频道来获取彼此的信息。
3.哨兵是通过INFO指令，从主库获取从库信息，并与每个从库建立连接，监控所有主从库状态。
4.哨兵是一个特殊的redis实例，所以客户端可以订阅哨兵的指定频道获得redis主从库的信息。
5.哨兵集群执行主从切换机制：谁发现，谁就发起投票流程，谁获得多数票，谁就是哨兵Leader，由Leader负责主从库切换。
6.哨兵集群Leader选举成功与否，依赖于网络通信状况，网络拥塞会导致选举失败，重新进行新一轮选举。
7. 哨兵投票机制：
a：哨兵实例只有在自己判定主库下线时，才会给自己投票，而其他的哨兵实例会把票投给第一个来要票的请求，其后的都拒绝。
b：如果出现多个哨兵同时发现主库下线并给自己投票，导致投票选举失败，就会触发新一轮投票，直至成功。

本文章仅用于学习记录，如有类同侵权，告知删除。