1、Redis 中的主库发生故障之后，会有什么影响？
如果是 Redis 中的从库故障了，并不影响对客户端提供服务，客户端可以向主库或者是其他从库发送请求，但是如果是主库发生了故障，虽然客户端的读请求可以发送给从库来执行操作，但是由于 Redis 的读写分离的机制，客户端的写操作必须交给主库来执行，同时主库的故障断开了与从库之间的数据同步，那么之后从库与那个数据进行数据库同步又是个问题。
2、主库故障之后，Redis 采取什么样的机制来解决？
对于主库可能发生故障的可能，Redis 利用哨兵机制来解决该问题。
3、哨兵机制能有什么功能，如何解决主库故障的场景？
哨兵机制提供的三个功能：（哨兵机制是实现主从库切换的关键机制）
- 判断主从库是否下线（监控）
- 当判断主库客观下线之后，选择一个合适的从库来替代主库（选主）
- 通知客户端及其其他从库最新的主库的相关信息，让其他从库与主库建立起连接（通知）
4、哨兵机制如何进行对主从库是否下线的监控的？
- 哨兵周期性向主从库发送 PING 命令，用于判断哨兵与主从库之间的网络连接状态，判断数据库是否处于在线状态，其中对于主从库判断其是否下线的措施不一样。
- 由于如果是从库下线了，其影响并不是很大，不会影响主库向客户端提供服务，因此，如果当哨兵向从库发送 PING 命令之后，如果从库未能在规定的时间内响应 PING 命令。那么就可以标记该从库“下线状态”。
- 但是如果某个哨兵向主库发送 PING，而主库未能在规定的时间内响应 PING，但是可能是由于集群环境下压力比较大，网络拥塞，或者是主库自身的压力就比较大，那么就可能存在主库未能即使返回 PING 响应，但是此时主库并没有下线，如果直接盲目地判断该主库已经处于“下线状态”，就会形成误判，而如果误判地次数过多过频繁就会造成进行主库切换的大量开销，然而为了减少这种因为误判而带来的开销，Redis 采取多个实例组成集群进行部署，称该集群为哨兵集群，哨兵集群中的所有哨兵都会进行主从库的监控，当一个主库未能在规定时间内响应某个哨兵的 PING 命令，那么该哨兵就会标记该主库处于“主观下线”，而最终要根据整个哨兵集群中对主库的监控判断以少数服从多数的原则，当哨兵集群中大比例的哨兵都主观判断主库处于下线状态，那么就可以标识主库处于“客观下线”的状态。接下来就需要进行主从切换的操作。
5、哨兵如何选择新的从库？
哨兵选择新主库的步骤可能划分为两部分：经过一定的筛选，再经过一定的规则进行打分，最终选择最高分的从库为最新的主库候选库。
- 一定的筛选：
- 此时从库处于在线状态，将标识为已下线的从库淘汰
- 将与主库频繁发生断连的从库淘汰，其中根据配置项来设计阈值表示断连多少次将被淘汰掉，例如配置项的值为 down_after_milliseconds * 10，（down_after_milliseconds 参数为与主库判断是否已经断连的最长超时时间）
- 一定的规则
- 首先进行从库优先级的比较，而从库的优先级我们是可以手动设置的，如果某个从库它的内存配置比较高的话，我们可以将该从库的优先级设置的高一些。在所有从库中选择出优先级最高的作为新主库。如果存在最高优先级的从库不止一个，那么进入下一轮选择。
- 根据当前从库的复制同步进度最高的为新的主库，由于再主库中的 repl_backlog_buffer 缓冲区中记录了主库的当前复制写的位置和从库复制读的位置，因此我们可以根据这个位置信息判断获取到复制进度最高的从库作为新主库，因为复制进度越高，相对于其他的从库，存储的数据就越新。但是如果存在复制进度最高的不止一个从库，那么就需要将它们进入最后一轮筛选。
- 每个实例再生成的时候都会生成一个唯一的 runID 的标识，因此选择最小的 runID 的从库最为新主库。
6、当新的主库切换好后，如何通知其他从库和客户端？
当完成主从切换之后，就需要哨兵会把新主库的信息发送给其它从库，让它们执行 replicaof 命令与新主库建立连接，并进行数据的同步，同时发送客户端新的主库的信息，当客户端发送请求的时候就可以发送给新的主库来执行。
7、根据在规定时间内是否对 PING 做出响应来判断主从库是否下线中的事时间长短的设置注意点。
其中未能在规定的时间内完成对 PING 响应的最长超时时间是由 down_after_milliseconds 参数来配置的，需要特别注意的是，应当将所有的哨兵的哨兵配置中的 dowm_after_milliseconds 的值设置为一致的，这样做是为了避免由于各个哨兵主观判断主库是否下线由于其最长超时时间不同导致一直未能达到共识，使得最后可能即使主库真正故障的时候，仍然不能及时得判断主库已经客观下线了，导致 Redis 长时间处于不可用的状态。
