参考官网
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 26379sentinel monitor mymaster ip port 2有三个配置就启动三个sentinel，整体流程图如下：
如果监听多组集群，能够设置多个monitor，比方
port 26379sentinel monitor mymaster ip port 2sentinel monitor resque ip port 2
原理局部前面章节解说