【LSP】Redis 高可用之哨兵模式

无名

哨兵模式
前面介绍了 Redis 的主从模式，主从模式只能实现读高可用，致命的弱点是写无法高可用，一旦 master 节点挂了，整个集群将无法写入数据，这并不符合我们对 Redis 高可用集群的期望。

那么，是不是有一种方法，可以做到不仅仅读高可用，写一样要高可用，当然有，这就是我们今天要介绍的哨兵模式。

哨兵模式可以理解成主从模式的一个升级版，主从模式 master 节点和 slave 节点是一开始就定好的，而在哨兵模式中， master 节点是可以转移，一旦发现当前的 master 节点挂掉，通过选举可以指定一个 slave 节点晋升成为 master ，保证在任何情况下，都有 master 节点可以支持写入操作，也间接实现了写高可用。

简介
哨兵模式可以看做是前面主从模式的一个升级版，主从模式没有故障转移， master 节点挂了就挂了，而哨兵模式就是为了解决这个问题而出现的。

集群监控：负责监控 Redis master 和 slave 进程是否正常工作。
消息通知：如果某个 Redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。
核心
假如我们现在有两个哨兵实例，就长下面这样：

+----+         +----+
| M1 |---------| R1 |
| S1 |         | S2 |
+----+         +----+
再了解两个参数： quorum 、 majority

quorum: 表示认为 master 宕机的哨兵数量。
majority: 表示授权进行主从切换的最少的哨兵数量，而这个数字，需要大于一半。
在只有两个节点的情况下，如果 master 宕机， s1 和 s2 中只要有 1 个哨兵认为 master 宕机了，就可以进行切换，同时 s1 和 s2 会选举出一个哨兵来执行故障转移。

这时，需要 majority，也就是大多数哨兵都是运行的。

所以此时，如果此时仅仅是 M1 进程宕机了，哨兵 s1 正常运行，那么故障转移是 OK 的。但是如果是整个 M1 和 S1 运行的机器宕机了，那么哨兵只有 1 个，此时就没有 majority 来允许执行故障转移，虽然另外一台机器上还有一个 R1，但是故障转移不会执行。

所以就有了以下这一条建议：

哨兵至少需要 3 个实例，来保证自己的健壮性，并且实例数量最好是奇数。
因为在进行选举的时候，需要超过一半的哨兵同意，也就是 majority 。

2 个哨兵，majority=2
3 个哨兵，majority=2
4 个哨兵，majority=2
5 个哨兵，majority=3
6 个哨兵，majority=3
7 个哨兵，majority=4
...
可以看到，只有在奇数的时候，是可以最大化的利用 majority 数量。

经典的三哨兵模型下面这样：

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+
如果 M1 所在机器宕机了，那么三个哨兵还剩下 2 个，S2 和 S3 可以一致认为 master 宕机了，然后选举出一个来执行故障转移，同时 3 个哨兵的 majority 是 2，所以还剩下的 2 个哨兵运行着，就可以允许执行故障转移。