Redis主从架构解决了服务负载的压力分担,读写分离有效的分离了流量.另外从库挂了，还有可以通过主库来持续进行服务。
如果主库挂了呢？在主库挂了的情况下,服务就停止了。我们可以通过重启来恢复服务，或者选择一个从库作为主库。
这里涉及三个问题:
1、主库是真的挂了，还是网络分区
2、以什么规则来选择从库作为主库
3、怎么把新的主库相关信息通知给从库和客户端
解决上述问题的方法就是哨兵机制。
哨兵机制的基本流程
- 监控
- 选主
- 通知
监控是哨兵进程在运行时,周期性给所有主从库发送PING命令,检测它们是否仍然在线运行。 在规定时间内没有响应哨兵PING命令就被标记为"下线状态",如果是主库下线就会开始自动切换主库的流程。
选主是哨兵需要从多个从库里按照一定的规则选择从库,作为新的主库。
通知是哨兵把新的主库连接信息发送给其他从库，让他们执行replicaof命令，和主库建立连接，并进行数据复制。 同时哨兵会把新主库的连接信息通知给客户端,让他们把写操作发送给新主库。
值得注意的两个点是:
- 监控任务中，哨兵如何判断主库下线
- 选主任务中，哨兵怎么决定选择哪个从库实例作为主库
下线状态分为主观下线、客观下线。哨兵进程会使用PING命令检测它自己和主、从库的网络连接情况。如果是从库无返回,由于集群对外不会间断服务,简单标记主观下线就可以了。如果是主库无返回,那么就需要讨论主库是否有误判的情况。一旦启动主从切换，后续选主通知都需要额外的计算和通信开销。误判一般是集群网络压力较大、网络拥塞、主库压力较大的情况下。
如何解决误判问题呢？为了解决哨兵误判的问题，哨兵通常采用多实例组成集群模型进行部署。 多个实例一起判断,多个哨兵网络同时不稳定的概率较小，一起决策能有效降低误判率。
当一个哨兵节点判断主库下线时，我们称为主观下线。当多数也就是半数以上的节点认为主库下线，才可以把主库标记为客观下线。
如何选主呢？哨兵采用的是筛选+打分的方式，这里和zookeeper很类似选主的机制大体都类似。
首先会检查从库当前的在线状态，网络连接状态，这里又一个配置项down-after-milliseconds 主从库断连的最大超时时间，大于此数则认为断连，断连次数大于10，则认为网络状态不好，不适合选为主库。
接下来给剩余的从库打分，按照从库优先级、从库复制进度、从库ID好给从库打分，得分最高的则选为主库。 配置项slave-priority可以设置从库优先级。在介绍主从同步的时候，我们介绍了主库会用master_repl_offset记录当前最新的写操作在repl_backlog_buffer的位置，从库会记录slave_repl_offset当前复制的进度。在优先级进度相同的情况下ID最小的从库当选。
