共计 3027 个字符，预计需要花费 8 分钟才能阅读完成。
哨兵机制
如果主库挂了，咱们就须要运行一个新主库，比如说把一个从库切换为主库，把它当成主库。
在 Redis 主从集群中，哨兵机制是实现主从库主动切换的要害机制，它无效地解决了主从复制模式下故障转移的这三个问题。
根本工作
- 监控：主库真的挂了吗？
a. 采纳多实例组成的集群模式进行部署，这也被称为哨兵集群。
b. 引入多个哨兵实例一起来判断， - 选主：抉择哪个从库作为主库？
a. 通过在线状态、网络情况筛选掉一部分从库
b. 再依据优先级、复制进度、从库的 id 进行打分
c. 得分最高的就是新的主库 - 告诉：把新主库的相干信息告诉给从库和客户端
监控
哨兵过程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否依然在线运行。如果从库没有在规定工夫内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；
同样，如果主库也没有在规定工夫内响应哨兵的 PING 命令，哨兵就会断定主库下线，而后开始主动切换主库的流程。
选出新主库
主库挂了当前，哨兵就须要从很多个从库里，依照肯定的规定抉择一个从库实例，把它作为新的主库。
告诉
- 哨兵会把新主库的连贯信息发给其余从库，让它们执行 replicaof 命令，和新主库建设连贯，并进行数据复制。
- 同时，哨兵会把新主库的连贯信息告诉给客户端，让它们把申请操作发到新主库上。
主观下线和主观下线
哨兵过程会应用 PING 命令检测它本人和主、从库的网络连接状况，用来判断实例的状态。
如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。
- 从库响应超时，哨兵能够间接标记为“主观下线”
- 主库须要哨兵集群一起判断，只有大多数的哨兵实例，都判断主库曾经“主观下线”了，主库才会被标记为“主观下线”
主观下线规范：
- 当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，能力最终断定主库为“主观下线”。
- 管理员可自行设定。
从新选主
在多个从库中，先依照肯定的筛选条件，把不符合条件的从库去掉。而后再依照肯定的规定，给剩下的从库一一打分，将得分最高的从库选为新主库。
筛选条件
在选主时，除了要查看从库的以后在线状态，还要判断它之前的网络连接状态。
判断网络连接状态：
down-after-milliseconds 是咱们认定主从库断连的最大连贯超时工夫。
如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络分割上，咱们就能够认为主从节点断连了。如果产生断连的次数超过了 10 次，就阐明这个从库的网络情况不好，不适宜作为新主库。
三轮打分
依照从库优先级、从库复制进度以及从库 ID 号进行打分。只有在某一轮中，有从库得分最高，那么它就是主库了，选主过程到此结束。如果没有呈现得分最高的从库，那么就持续进行下一轮。
- 优先级：slave-priority 配置项
- 复制进度：slave_repl_offset 最靠近 master_repl_offset
- ID 号：ID 号最小的从库得分最高
小结
Redis 的哨兵机制主动实现了以下三大性能，从而实现了主从库的主动切换，能够升高 Redis 集群的运维开销：
- 监控主库运行状态，并判断主库是否主观下线；
- 在主库主观下线后，选取新主库；
- 选出新主库后，告诉从库和客户端。
问题：哨兵在操作主从切换的过程中，客户端是否失常地进行申请操作？
答复：如果客户端应用了读写拆散，那么读申请能够在从库上失常执行，不会受到影响。然而因为此时主库曾经挂了，而且哨兵还没有选出新的主库，所以在这期间写申请会失败，失败继续的工夫 = 哨兵切换主从的工夫 + 客户端感知到新主库 的工夫。
08 哨兵集群
配置哨兵信息
sentinel monitor <master-name> <ip> <redis-port> <quorum> 集群组成
哨兵实例之间能够互相发现，要归功于 Redis 提供的 pub/sub 机制，也就是公布 / 订阅机制。
哨兵只有和主库建设起了连贯，就能够在主库上公布音讯了，比如说公布它本人的连贯信息（IP 和端口）。同时，它也能够从主库上订阅音讯，取得其余哨兵公布的连贯信息。
Redis 会以频道的模式，对这些音讯进行分门别类的治理。
所谓的频道，实际上就是音讯的类别。当音讯类别雷同时，它们就属于同一个频道。反之，就属于不同的频道。只有订阅了同一个频道的利用，能力通过公布的音讯进行信息替换。
哨兵互连：
在主从集群中，主库上有一个名为“__sentinel__:hello”的频道，不同哨兵就是通过它来互相发现，实现相互通信的。
哨兵连贯从库：
哨兵向主库发送 INFO 命令，主库承受到这个命令后，就会把从库列表返回给哨兵。
哨兵能够依据从库列表中的连贯信息，和每个从库建设连贯，并在这个连贯上继续地对从库进行监控。
客户端事件告诉
哨兵是一个运行在特定模式下的 Redis 实例，它并不服务申请操作，只是实现监控、选主和告诉的工作。
每个哨兵实例也提供 pub/sub 机制，客户端能够从哨兵订阅音讯。
哨兵提供的音讯订阅频道有很多，不同频道蕴含了主从库切换过程中的不同要害事件。
客户端读取哨兵的配置文件后，能够取得哨兵的地址和端口，和哨兵建设网络连接。而后，咱们能够在客户端执行订阅命令，来获取不同的事件音讯。
举例：
- 订阅“所有实例进入主观下线状态的事件”：
SUBSCRIBE +odown - 订阅所有的事件：
PSUBSCRIBE *
选举执行
- 任何一个实例只有本身判断主库“主观下线”后，就会给其余实例发送 is-master-down-by-addr 命令。
- 接着，其余实例会依据本人和主库的连贯状况，做出 Y 或 N 的响应，Y 相当于赞成票，N 相当于反对票。
- 一个取得了仲裁所需的赞成票数后，就能够标记主库为“主观下线”。这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。
-
这个哨兵就能够再给其余哨兵发送命令，表明心愿由本人来执行主从切换，并让所有其余哨兵进行投票。这个投票过程称为“Leader 选举”。胜利条件：
- 拿到半数以上的赞成票
- 票数大于等于 quorum
如果选举没有胜利，那么这轮投票就不会产生 Leader。哨兵集群会期待一段时间（也就是哨兵故障转移超时工夫的 2 倍），再从新选举。
留神：如果哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须取得 2 票，而不是 1 票。所以，如果有个哨兵挂掉了，那么，此时的集群是无奈进行主从库切换的。因而，通常咱们至多会配置 3 个哨兵实例。
小结
哨兵集群的要害机制：
- 基于 pub/sub 机制的哨兵集群组成过程；
- 基于 INFO 命令的从库列表，这能够帮忙哨兵和从库建设连贯；
- 基于哨兵本身的 pub/sub 性能，这实现了客户端和哨兵之间的事件告诉。
留神：要保障所有哨兵实例的配置是统一的，尤其是主观下线的判断值 down-after-milliseconds。
问题：Redis 1 主 4 从，5 个哨兵，哨兵配置 quorum 为 2，如果 3 个哨兵故障，当主库宕机时，哨兵是否判断主库“主观下线”？是否主动切换？
答复：
1、哨兵集群能够断定主库“主观下线”。因为 quorum=2，所以当一个哨兵判断主库“主观下线”后，询问另外一个哨兵后也会失去同样的后果，2 个哨兵都断定“主观下线”，达到了 quorum 的值，因而，哨兵集群能够断定主库为“主观下线”。
2、但哨兵不能实现主从切换。哨兵标记主库“主观下线后”，在选举“哨兵领导者”时，一个哨兵必须拿到超过少数的选票 (5/2+1= 3 票)。但目前只有 2 个哨兵活着，无论怎么投票，一个哨兵最多只能拿到 2 票，永远无奈达到少数选票的后果。
