一. 前言
为什么要用哨兵?
哨兵(Sentinel)主要是为了解决在主从复制架构中出现宕机的情况,主要分为两种情况:
- 从Redis宕机：这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据。在Redis2.8版本后，主从断线后恢复的情况下实现增量复制。
- 主Redis宕机：这个相对而言就会复杂一些，需要以下2步才能完成
（1）第一步,在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务；
（2）第二步,将主库重新启动后,执行SLAVEOF命令,将其设置为其他库的从库,这时数据就能更新回来。
由于这个手动完成恢复的过程其实是比较麻烦的并且容易出错,所以Redis提供的哨兵(sentinel)的功能来解决
二. 哨兵(Sentinel)简介
哨兵(后文统称sentinel)是官方推荐的的高可用(HA)解决方案。在之前的文章中介绍过redis的主从高可用解决方案，这种方案的缺点在于当master故障时候，需要手动进行故障恢复，而sentinel是一个独立运行的进程，它能监控一个或多个主从集群，并能在master故障时候自动进行故障转移，更为理想的是sentinel本身是一个分布式系统，其分布式设计思想有点类似于zookeeper，当某个时候Master故障后，sentinel集群采用Raft算法来选取Leader，故障转移由Leader完成。而对于客户端来说，操作redis的主节点，我们只需要询问sentinel，sentinel返回当前可用的master，这样一来客户端不需要关注的切换而引发的客户端配置变更。一个典型的sentinel架构如下图：
sentinel的主要功能：
- 监控(Monitoring): sentinel 会不断地检查Master和Slave是否运作正常。
- 通知(Notification):当被监控的某个Redis实例出现问题时，哨兵(sentinel) 可以通过 API向管理员或者其他应用程序发送通知。
- 自动故障迁移(Automatic failover):当一个Master不能正常工作时，sentinel)会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用Master代替失效Master。
- 配置中心(Configuration provider)：如果故障转移发生了，sentinel会返回新的master地址。