第七章 哨兵机制：主库挂了，如何不间断服务 ?
哨兵机制的基本流程
哨兵的主要职责：
- 监控：通过 PING命令 来监控主从
- 选主：主库挂了，在从库中按一定的机制选择一个作为新主库
- 通知：通知其他从库和客户端新的主库信息
- 让其他从库执行 replicaof 命令，和新主库建立连接，并进行数据复制
监控：主观下线和客观下线
哨兵对主库的下线判断有“主观下线”和“客观下线”两种。
什么是主观下线 ?
- 哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。
- 如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。
- 对于从库，可以简单标记为“主观下线”。
- 对于主库，还需要考虑哨兵是否出现误判的情况。误判一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下。
哨兵机制怎么减少误判呢 ?
- 为了防止单个哨兵误判，可以引入多个哨兵实例一起来判断，这样可以避免单个哨兵因为自身网络状况不好，而出现误判主库下线的情况
- 只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”
什么是客观下线 ?
- “客观下线”的标准就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。
- 也可以由 Redis 管理员自行设定。
选主：如何选定新主库？
- 在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。
- 从库是否在线
- 从库的网络连接状态
- 然后，再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库。
- 分为三轮打分，前一轮平分才会进入下一轮打分，只要在某一轮有从库得分最高，就可以选择该从库作为主库：
- 从库优先级
- 从库复制进度
- 从库 ID 号
具体的打分情况是什么样的呢 ?
- 第一轮：优先级最高的从库得分高。
- 第一轮：优先级最高的从库得分高。
- 通过上一章所讲的 slave_repl_offset，最接近旧主库 master_repl_offset 的得分最高。
- 第三轮：ID 号小的从库得分高。
- Redis 在选主库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。
- 最小的说明最早连接上，数据也就最全，能活到现在也就最稳定，毕竟久经考验。
总结
Redis 的哨兵机制自动完成了以下三大功能：
- 监控主库运行状态，并判断主库是否客观下线；
- 在主库客观下线后，选取新主库；
- 选出新主库后，通知从库和客户端。
问题
哨兵集群中有实例挂了，怎么办，会影响主库状态判断和选主吗 ?
- 存在故障节点时，只要集群中大多数节点状态正常，集群依旧可以对外提供服务。
主从库切换是需要一定时间的。在这个切换过程中，客户端能否正常地进行请求操作呢 ?如果想要应用程序不感知服务的中断，还需要哨兵或需要客户端再做些什么吗？
- 主库下线，可读不可写，写失败的时间 = 哨兵切换主从的时间 + 客户端感知新主库时间
- 主库下线无感知，需要客户端与哨兵配合改造：
- 哨兵主动通知：哨兵需要将最新的主库地址写入自己的
pubsub 中，客户端需要订阅这个 pubsub，当这个 pubsub 有数据时，客户端就能感知到 - 客户端主动获取：客户端不将主从库写死，而是从哨兵集群中获取，从而始终获取最新的主从地址
