这篇文章主要讲解了如何使用Redis中的高可用组件sentinel，内容清晰明了，对此有兴趣的小伙伴可以学习一下，相信大家阅读完之后会有帮助。
今天我们来聊一下redis的高可用组件sentinel；首先来回顾下redis的主从同步，主从同步最主要的作用是让master的数据在其他服务器上实时存在副本，起到了备份的效果；对于redis的读写来说，主从架构能够让读的请求分散到多个从服务器上，从而降低了单台redis读请求的io压力，同时也提高了redis读请求的并发能力；通常为了数据的一致性，从服务器一旦成为某一台redis的slave，那么从服务器上之前有的数据会被清空，然后把master发送过来的数据应用到内存，从而实现和master数据一致；除此之外slave通常会是只读属性，也就说slave端只能执行读操作，写操作会被拒绝，所以写请求始终是由master来完成；那么问题来了，对于这种主从复制架构的环境中，如果master宕机了，master宕机意味着整个系统将不能够写数据到redis,很显然这种情况我们应该及时解决；怎么解决呢？有没有这样的一组件帮我们对master做实时的监控，一旦发现master宕机就提升一个slave当选新的master，如果原master还有其他slave，将其他slave都从属于新的master；除此之外它还应该让系统在发生切换master时触发报警通知，让管理员尽快把坏掉的master修复上线；对，sentinel就有我们上述的这些功能，它能够监控主从同步集群中的master节点，在master发生宕机后能够自动故障转移，将提升一台slave作为新的master，然后通知管理员；
Sentinel是一个分布式系统，我们可以在一个架构中运行多个sentinel，这些sentinel进程使用流言协议（gossipprotocols）来接收关于 Master是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个sentinel进程会向其他sentinel进程、master、slave定时发送消息，以确保对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称：Subjective Down，简称 SDOWN。有主观宕机，肯定就有客观宕机。当多个sentinel进程中多数的sentinel进程在对 Master 做出 SDOWN 的判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的 Master Server 下线判断，这种方式就是“客观宕机”，英文名称是：Objectively Down， 简称 ODOWN。通过一定的 vote 算法，从剩下的 slave 从服务器节点中，选一台提升为 Master 服务器节点，然后自动修改相关配置，并开启故障转移（failover）。
配置使用sentinel
环境说明
角色ip地址端口master192.168.0.416379slave01192.168.0.426379slave02192.168.0.436379sentinel01192.168.0.4126379sentinel02192.168.0.4226379sentinel03192.168.0.4326379架构图
提示：从上面的架构图可以知道，首先我们必须要有一个主从架构的集群，然后在部署sentinel 来对主从同步集群做监控；
redis主从复制集群搭建
1、在192.168.0.41/42/43上安装redis，可以使用yum安装，也可以使用编译安装，redis安装请参考https://www.cnblogs.com/qiuhom-1874/p/13378138.html；
2、配置192.168.0.41/42/43上的redis监听在非本机127.0.0.1上并配置42/43上的redis从属于192.168.0.41
master
slave01
slave02
提示：redis支持在线修改配置，保存配置到配置文件；SLAVEOF 指令用于指定redismaster的ip地址和端口，表示把该redis配置成对应master的slave角色；CONFIG REWRITE是把我们的配置保存到配置文件；
在master上查看是否有两个从节点连接到master
验证：在master上写数据，看看是否能够及时同步到两个slave上？
