共计 1355 个字符，预计需要花费 4 分钟才能阅读完成。
以下均在单机环境下测试：
实例 A（主 127.0.0.1:16379 master）
实例 B（主 127.0.0.1:16380 slave1）
实例 C（主 127.0.0.1:16381 slave2）
失常主从 redis 服务图：
master 异样图：
由图可知，当 master 异样时，客户端不能写数据，从库不能从主库同步数据，这时候，咱们就须要运行一个新的主库，这里就波及到三个问题。
- 主库是否真的挂了？
- 主库挂了的话，选哪个从库来充当主库？
- 如何把新主库通知从库和客户端？
哨兵机制，帮你解决所有问题。
哨兵机制次要性能：监控，选举，告诉
监控：判断主库是否挂了，判断分为两种：主观下线，主观下线。
主观下线：每个 sentinel 节点（哨兵节点）对 redis 节点的偏见
主观下线：所有 sentinel 节点（哨兵节点）对 redis 节点达成统
选举：选出新的主库
告诉：告诉客户端和其余从库
监控：哨兵 ping 从库，咦，ping 超时了，间接标记为主观下线（此实例就不可用于服务）。哨兵 ping 主库，咦，也是 ping 不通，然而不能间接标记为主观下线，因为 可能存在误判，误判会导致主从切换，带来不必要的切换开销，如从新选举，通信开销。
误判：主库没下线，哨兵认为主库下线了，可能呈现起因：集群网络压力较大、网络拥塞，或者是主库自身压力较大。那怎么缩小监控时的误判呢？
采纳哨兵集群判断，由多个哨兵判断主库主观下线了，主库才会标记为主观下线。
判断后果为下线：
判断后果为上线：
主观下线的规范就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，能力最终断定主库为“主观下线”
如何选举新主库？
筛选 + 打分
咱们选新主库，必定是要新主库稳固，防止切换后再次发生主从切换。
先对新主库进行筛选：次要是判断新从库在线状态和网络连接状况。网络连接判断：能够判断 sentinel 配置 down-after-milliseconds * 10，超过最大连贯超时工夫 10 次，则从库网络不稳固，不适合做新主库。
打分：分为三轮规定。从库优先级、从库复制进度以及从库 ID 号
从库优先级：
如果从库的机器实例 B（在此为 16380 端口）绝对比拟高配，能够通过 redis.conf 设置分高一点，比方设置为 100 分。
实例 C（在此为 16381 端口）绝对比拟低配，能够设置为 70 分。
此时 master 宕机，选举就会产生了，在此，咱们先来试验一下。
启动哨兵，哨兵 1 为例子:port 23680
此时，让 master（实例 A，16379）下线。
察看哨兵反馈。
再次查看主从状态
再次启动实例 A（16379），发现实例 A 变成了从库，成为实例 B 的主库。
如果从库优先级优先级统一，则 旧主库同步水平最靠近的从库得分高，该从库成为新主库（起码缩小数据失落）
如果从库的 slave_repl_offset 都统一，则须要进行第三次打分。
每个实例都会有一个 ID，这个 ID 就相似于这里的从库的编号。目前，Redis 在选主库时，有一个默认的规定：在优先级和复制进度都雷同的状况下，**ID 号最小的从库得分最高，会被选为新主库
**
到此，主库切换就实现了。
总结：哨兵会依照在线状态、网络状态，筛选过滤掉一部分不符合要求的从库，而后，顺次依照优先级、复制进度、ID 号大小再对残余的从库进行打分，只有有得分最高的从库呈现，就把它选为新主库。
