关于redis:redis-哨兵高可用

参考官网
redis – 主从（高性能）中，提供了高性能，然而没方法提供高可用。比方 master 挂了，尽管 slave 能够提供查问，然而不能提供写入服务，绝对于不可用了。尽管能够把 slave 通过 slaveof no one 命令变成 master，然而手动还是不太不便。
redis 能够应用 sentinel 主动实现故障发现和转移，并提供了以下性能：

1. 监控：监控 master 和 slave 是否失常工作。
2. 告诉：当发现某个 redis 异样时，能够告诉应用程序或者系统管理员。
3. 故障转移：当 master 出现异常时，sentinel 会选举一个新的 master，并让其余 slave 指向新的 master 地址，同时告诉应用程序应用新的 master 地址。
4. 配置核心：产生故障转移时，告诉新 master 地址。

为了 sentinel 的健壮性，sentinel 也是分布式的，多个 sentinel 协同工作的劣势如下：

• master 是否失常工作，由大部分的 sentinel 决定的，缩小误判的概率。
• 局部 sentinel 的异样，并不障碍整体的性能。

部署案例

在部署之前，咱们须要理解一下根本信息：

• 为了保障 Sentinel 服务的健壮性，至多须要三个 Sentinel 实例。
• 三个示例应该放在不同的虚拟机或物理机上。
• 因为 redis 的异步复制，所以 Sentinel 不保证数据的零失落。

两个实例

+----+         +----+
| M1 |---------| R1 |
| S1 |         | S2 |
+----+         +----+

配置: quorum = 1

这个示例中，一个服务器部署了 Mater 和 Sentinel，一个服务器部署了 slave 和 Sentinel。此时，如果 M1 挂了，S1 和 S2 只有有一个认为 M1 挂了，就会选举一个 Sentinel 让 slave 降级为 master，然而如果 M1 所在的服务器异样了，则只剩下 S2，此时 1 小于 majority(2) 是无奈做故障转移的。

三个实例

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+

配置:  quorum = 2

这个示例中，如果 M1 所在服务器挂了，此时 S2 和 S3 只有有一个认为 M1 挂了，就就会选举一个 Sentinel 做故障转移，此时 2 个 Sentinel 大于等于 majority(2) 是能够做故障转移的。
以上两个是比拟典型的案例，当然官网还有跟客户端一个服务器的。至于为什么要一起部署，是因为咱们服务器的资源是贵重（要钱）的，一起部署既达到了服务的健壮性，也节约了资源。

简略示例

首先是主从，在 redis – 主从（高性能）中也说了如何配置，sentinel 的配置也比较简单，如下：

port 26379
sentinel monitor mymaster ip port 2

有三个配置就启动三个 sentinel，整体流程图如下：

如果监听多组集群，能够设置多个 monitor，比方

port 26379
sentinel monitor mymaster ip port 2
sentinel monitor resque ip port 2

原理局部前面章节解说