【redis哨兵机制导读】上一节介绍了redis主从同步的机制，但大家有没有想过一种场景，比如：主库突然挂了，那么按照读写分离的设计思想，此时redis集群只有从库才能提供读服务，那么写服务该如何提供，主库挂了，恢复主库也需要一定的时间，不可能这段时间不给业务方提供写服务吧！基于这样的背景，哨兵机制就应运而生。

就好比如下的场景，redis集群是没法给外界提供写服务的。那比如此时是淘宝双11活动期间，那用户就没法下单了，只能查询订单了。
redis就此推出了哨兵机制，何为哨兵机制？哨兵其实就是运行在特殊模式下的redis进程，特殊模式下的redis进程其实并不对外提供服务，它们的作用就是监控redis集群中所有的主库和从库。怎样监控呢？定期PING所有的主、从库，如果从库没有回应哨兵的PING请求，那么从库会被标记为"下线状态"，影响倒不大；如果主库没有回应PING请求，那么哨兵会认为主库挂了，随后便开始自动切换主库的流程。

那如何实现自主切换主库流程？哨兵会按照一定的规则，从众多从库中选出一个从库作为主库，随后将新选出的主库信息同步给其它的从库，让从库执行replicaof 命令，从新主库上同步数据；最后将新主库的信息发给客户端，让客户端给新主库发送请求。整体的流程可以用如下流程图进行概括。

那是否存在哨兵误判的情况？
答案是肯定的，因为主库要扛住那么高的并发请求，网络带宽的压力肯定很大，那是否存在一种可能，哨兵主动PING主库，主库没来得及回应，此时如果哨兵就单纯地认为主库下线了，就显得不客观，主库便被认定为"主观下线"。基于这一现状，redis推出除了哨兵集群，也就是在多个主机上分别运行多个哨兵，构建成一个哨兵集群，这些哨兵同时监控所有的主库和从库，假设有超过半数以上的哨兵没法和主库PING通，那么此时主库大概率是下线，主库此时便被认定为"客观下线"。
主库"客观下线"了，哨兵就要开启选新主库的流程了，那选新主库也是有一定的策略和规则的。主要分为筛选和打分两个流程，筛选主要是把那些下线的从库给剔除掉，选出一批在线的从库。随后进入打分环节。主要包括以下三步：

第一轮：优先级最高的从库得分高

从库优先级可以走配置，用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级，如果选出了优先级最高的从库，那么这个从库就是新的主库了。

第二轮：和旧主库同步程度最接近的从库得分高

何为从库与主库最接近？记得上一节我们提过的环形队列repl_backlog_buffer，环形队列中有两个偏移量master_repl_offset、slave_repl_offset，这两个偏移量的意义，我就不过多介绍了。如果那个从库的slave_repl_offset和主库的master_repl_offset差值最小，那说明该从库和旧主库的数据差异最小，即当前从库就是最新的主库。

第三轮：ID 号小的从库得分高

记得前几节内容提过，每个redis进程都默认有个ID值，ID值最小的，那得分最高，也即是最容易被选为主库。

哨兵集群，经历过上述三个打分流程，肯定能从众多从库中选出最新的主库。