共计 1645 个字符，预计需要花费 5 分钟才能阅读完成。
redis – 哨兵（高可用）提了哨兵的作用以及简略配置，这边就讲一讲他的原理。
哨兵是怎么发现其余哨兵的
哨兵与哨兵之间，是须要晓得其余哨兵的衰弱状况以及信息的分享，咱们在后面的配置中，并没有看到其余哨兵地址的配置，只配置了 master 的地址。哨兵通过 redis 的 Pub/Sub 性能，发现也监督的 master/slave 的其余哨兵。
哨兵会往名字为__sentinel__:hello 的 Channel 里发送 hello，此时其余的哨兵就能够接管到音讯，并晓得其余哨兵的存在。
- 每隔两秒，会向__sentinel__:hello 的 Channel 发送音讯，内容包含 ip, port, runid。
- Hello 音讯还包含主服务器的残缺以后配置。如果接管哨兵为给定的主服务器配置了比接管到的更老的配置，它会立刻更新到新的配置。
- 每个哨兵会监听_sentinel__:hello 的 Channel 的音讯，当他发现其余哨兵的信息时，就会被退出哨兵群里。
- 退出哨兵群里之前，他会判断 runid 是否一样，或者 ip+port 是否一样，如果一样，旧的信息降被移除，用新的信息代替。
哨兵是怎么晓得 master 挂了
每个哨兵，都会给每个节点发送 ping 申请（上面只画了 master，slave 也会发送 ping 申请），如果节点在 down-after-milliseconds（sentinel 的配置，比方 30 秒）内没有响应 sentinel- 1 的 ping 申请，则咱们认为他是被动下线了（SDOWN），如果 sentinel- 2 也发现他没有响应 ping 申请了，此时两个 sentinel 大于等于 quorum（此时是 2），则咱们认为他是主观下线了（ODOWN）。也能够这么了解，比方路人甲认为路人乙很坏，可能是因为他跟路人乙有矛盾，主观的认为他坏，其他人可能并不认可他的想法，所以是主观下线。然而路人丙路人丁等少数人感觉路人很坏，那很可能路人乙真的坏，大家的评估是主观的，所以是主观下线。
那咱们以什么判断是达到了 ODOWN 的条件呢，就是咱们之前配置的 Quorum，然而是否进行故障转移，也要思考到 majority，也就是数量要达到 majority 才运行受权做故障转移。
比方有 5 个哨兵，Quorum 设置为 2，majority 设置为 3，此时 master 没响应哨兵的数量为 2，曾经达到 ODOWN 的条件了，还是不能做故障转移，只有达到 3 的时候，才能够做故障转移。
如果 Quorum 设置为 3，majority 设置为 2，此时 master 没响应哨兵的数量为 2，尽管能够受权做故障转移，然而并没有达到 ODOWN 的条件，还是不能做故障转移。
哨兵是怎么选举 master 的
当 master 被认为是 ODOWN 的时候，哨兵会通过以下几个选举一个 slave 为 master：
- 从 master 断开的工夫
- slave 的优先级
- offset 的值
- Run ID
如果 slave 和 master 的断开工夫超过 down-after-milliseconds 的 10 倍 +master 的 SDOWN 的时长，则不思考切换为 master，公示如下：
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_stateslave 被选举为 master 的程序如下：
- redis.conf 配置的优先级，replica-priority 越低优先级越高。
- 优先级一样，看 offset，offset 越大，阐明对 master 的同步数据越多。
- 看 offset 也一样，则抉择 runid 最小的，抉择最小的是为了在抉择的时候有更多的确定性，而不是随机选一个。
确定了哪个 slave 降级为 master，那哨兵也是要从哨兵中选举一个来做这些操作的。
- 对应的 slave 执行 slaveof no one，把 slave 的 role 移除，变为新的 master。
- 告诉其余的 slav 指向新的 master。
- 告诉应用程序指向新的 master。
- 出故障的原 master 重启后，成为新 master 的 slave 节点。
