0.基本概念
-
从库故障可以忽略，整体还是可以继续向下运行
-
如果主库挂掉，所有的写操作都不能完成
-
所以为了保证服务的高可用，当主库挂掉后，选举一个从库作为新的主库
-
需要思考的地方（哨兵机制）
- 主库真的挂了吗
- 选择那个从库作为主库
- 怎么通知客户端和从库新的主库
\
1.哨兵机制的基本流程
-
哨兵其实就是一个运行在特殊模式下的 Redis 进程\
-
执行三个任务
- 监控（主库是否存活）
- 选主（选择主库）
- 通知（通知客户端和从库）
-
监控（正常，主观下线，客观下线）
-
周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行（相比于检测端口更通用，数据量更小）\
-
如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”\
-
如果主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，然后开始自动切换主库的流程\
-
-
选主
- 从从库中选举新的节点作为主库
-
通知
-
哨兵会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进行数据复制\
-
哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上
-
\
2.主观下线和客观下线
-
哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态\
-
主观下线（可能存在误判）
-
主库或从库对 PING 命令的响应超时了\
-
从库直接下线即可
-
主库需要继续判断
-
误判一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下
-
**采用多实例组成的集群模式进行部署，这也被称为哨兵集群
** -
**引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况
**
-
-
客观下线
-
只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”\
-
当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线” ，才能最终判定主库为“客观下线”
-
\
3.如何选定新主库
-
哨兵选择新主库的过程称为“筛选 + 打分”\
-
首先根据一定的条件进行筛选（筛选出网络不稳定的节点）
-
除了要检查从库的当前在线状态，还要判断它之前的网络连接状态\
-
down-after-milliseconds * 10\
-
主从库断连的最大连接超时时间\
-
-
再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库\
-
从库优先级、从库复制进度以及从库 ID 号\
-
第一轮：优先级最高的从库得分高\
-
用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级\
-
从库优先级一样高，进入下一轮
-
-
第二轮：和旧主库同步程度最接近的从库得分高\
- 从库数据最接近主库数据
- 通过master_repl_offset和slave_repl_offset在repl_backlog_buffer的位置判定
- 同步程度接近的，进入下一轮
-
第三轮：ID 号小的从库得分高\
- ID号小的选举出来
-
\
4.总结
-
选举过程
- 首先，哨兵会按照在线状态、网络状态，筛选过滤掉一部分不符合要求的从库
- 然后，依次按照优先级、复制进度、ID 号大小再对剩余的从库进行打分，只要有得分最高的从库出现，就把它选为新主库\
-
哨兵集群的作用
- 监控主库运行状态，并判断主库是否客观下线
- 在主库客观下线后，选取新主库
- 选出新主库后，通知从库和客户端\
-
哨兵个数为奇数个
-
哨兵集群中有实例挂了，怎么办，会影响主库状态判断和选主吗？\
-
哨兵集群多数实例达成共识，判断出主库“客观下线”后，由哪个实例来执行主从切换呢？\
\
