哨兵（sentinel）在Redis主从架构中是一个非常重要的组件，是在Redis2.8版本引入的。它的主要作用就是监控所有的Redis实例，并实现master节点的故障转移。哨兵是一个特殊的redis服务，它不负责数据的读写，只用来监控Redis实例。
Redis sentinel工作原理
在哨兵模式架构中，client端在首次访问Redis服务时，实际上访问的是哨兵（sentinel），sentinel会将自己监控的Redis实例的master节点信息返回给client端，client后续就会直接访问Redis的master节点，并不是每次都从哨兵处获取master节点的信息。
sentinel会实时监控所有的Redis实例是否可用，当监控到Redis的master节点发生故障后，会从剩余的slave节点中选举出一个作为新的master节点提供服务，并将新master节点的地址通知给client端，其他的slave节点会通过slaveof命令重新挂载到新的master节点下。当原来的master节点恢复后，也会作为slave节点挂在新的master节点下。
哨兵架构下client端第一次从哨兵找出redis的主节点(client不是一开始就连接redis服务，而是先连接哨兵服务，从哨兵服务上获取到redis服务的信息后，之后直接访问redis服务)，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点。
当redis的主节点发生变化（ master节点如果挂掉之后，哨兵会选举出新的master节点），哨兵会第一时间感知到，并且 将新的redis主节点通知给client端（这样就可以实现高可用了，即一个master节点挂了之后，哨兵会自动选举出另一个新的master节点，并将新master节点的信息发送给客户端）(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)。
深入思考：
我们客户端连接哨兵模式的redis的时候，连接地址自然是要写哨兵的，肯定不能写某个redis服务的IP+端口。为什么？
一旦我们的redis服务的主节点挂掉之后，如果我们采用的是直接写redis服务的IP+端口的模式，根本不可能成功访问，因为这个服务已经挂掉了。
所以说我们要找一个中介点，让其管理redis服务的连接信息，而我们客户端只需要连接到这个中介点上，每次都动态的去这个中介点上去拉取redis的主节点的连接信息就好了。
这样，即使redis服务的主节点挂了，redis服务会把新选举出来的主节点的信息更新到这个中介点上，我们服务端只需要去这个中介点上再拉取一次，就可以获取到新的主节点的信息了，而此时我们对于这个中介点的配置是没有改变的，所以这样就实现了Redis的高可用。
这种思想与使用KeepAlive + HAproxy是一模一样的，IP地址不能写真实服务地址，而是写一个中间服务的地址，然后由这个中间服务去拉取真实的服务地址。
