关于redis:redis-哨兵高可用

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

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

原理局部前面章节解说

关于redis:redis-哨兵高可用

部署案例

两个实例

三个实例

简略示例