Redis哨兵(Sentinel)其实本质就是一个RedisServer节点，通过设置 运行模式 来开启哨兵的功能；主要功能如下：

• 监控（Monitoring ）：哨兵节点会不断地检查的主服务和从服务的运行状态；
• 自动故障迁移（Automatic failover） ：当Redis主从模式中的主服务器发生故障时，哨兵节点会根据一定的策略自动进行故障迁移，即在原有主服务器下的从服务器中，自动选出一个从服务器作为新的主服务器，及时处理故障；
• 通知（Notification） ：当被监控的Redis服务器故障时，哨兵节点可以向相关人员或客户端发送通知提醒；
• 配置提供者（Configuration provider） ：可以通过哨兵节点为客户端提供主从模式中的主节点地址，这里的客户端指平时写的程序；

老规矩，还是先不说那么多理论，先来实操一把，然后再来总结：

哨兵模式搭建

先来个最基础的：一个哨兵监控一主二从的环境；后面小伙伴就知道如何扩展啦，如下图所示(这里通过一台机器演示，所以通过端口进行区分各个redis节点)：

Redis哨兵模式是基于Redis主从复制的，所以先来搭建主从复制环境，这个过程在 上一篇 中已经详细分享，这里就不细说，直接动手啦；

1. 搭建主从复制环境，如上图所示，6377作为主服务器，6388和6399作为从服务器，这里是通过配置文件的形式修改，最终效果如下：
2. 主从复制环境搭建完毕之后，接下来需要有一个哨兵对其进行监控；之前有说过，Redis的功能通过配置文件就能快速实现，针对哨兵有一个单独的配置文件，这里就起名为： sentinel.conf ，内容如下：sentinel monitor mymaster 127.0.0.1 6377 1大概意思就是哨兵要监控对应的主服务器，其他啥都不用配置；这里对于配置文件内容先不解释这么多，接下来会专门进行介绍，先把环境搭建起来，玩一把再说；
3. 启动哨兵，两种方式：redis-sentinel启动，redis-sentinel其实是用redis的一个代码分支分离出来的，安装完redis就有，命令如下：./redis-sentinel ZoeConfig/sentinel.confredis-server启动，指定为哨兵模式即可，命令如下：./redis-server ZoeConfig/sentinel.conf --sentinel启动效果如下：如上图所示，Redis哨兵其实本质还是一个Redis节点，只是运行模式不一样而已；
4. 哨兵模式运行起来，模拟主服务器宕机，这里直接将6377服务器shutdown, 注意看哨兵打印的日志：先将主服务器6377关掉，如下：由于哨兵定时对主服务器进行监控，如果在30秒内(默认30秒)发现主服务器无法正常通讯时，就开始进行投票选举原主服务器下的从服务器作为新主服务器，哨兵打印日志如下：大概流程如下图：哨兵最后的状态会持久化到指定的配置文件中，之前只是简单配置了一条监控语句，现在如下：
5. 验证故障转移结果；光说6388变成了主服务器没证据，连上6388看看，同时再看看6399有没有换新主人，如下图：6388主从信息：对应的配置文件中将之前的主从关系配置已经去掉了。6399主从信息：对应的配置文件也已经改了，如下：

以上就完成了哨兵模式搭建的演示啦，是不是很简单，只要稍微改改配置文件即可完成自动化故障恢复。 到这小伙伴可能会问，原来故障的主服务器恢复了会怎么样？ 一个哨兵误判主服务器下线或高并发抗不住怎么办？嘿嘿嘿，接着来搞，接下来边操作边总结；

原故障的主服务器恢复之后只能当小兵

原有通讯异常的主服务器如果恢复正常，那它还能恢复原来的地位吗？，还是另有安排呢？这个很好演示，直接将之前shutdown的主服务器重新起来即可；6377启动后查看主从关系信息如下图：

如上图实操验证，原来异常的主服务器(6377)恢复之后就变成新主服务器(6388)的从服务器了(原来再屌，现在也只是小弟，重新再混等机会)。

哨兵集群高可用

以上演示就一个哨兵，这样有很明显的两个缺点，如下：

• 单个哨兵容易导致误判主节点下线，比如主节点正常，只是在与哨兵之间通讯出现短暂异常，如果是单个哨兵，在指定的时间间隔没有通讯就认为主节点下线了，但其实没有；如果哨兵集群，可以询问多个哨兵指定的主节点是否下线，这样就显得更有保障；
• 哨兵挂了，故障转移就没法继续啦，哨兵集群的话就会选择其他哨兵继续处理；

配置哨兵集群超级简单，就是增加节点即可，哨兵节点会通过发布与订阅功能来自动发现正在监视 相同主服务器 的其他哨兵 ， 这一功能是通过向频道 sentinel :hello 发送信息来实现的。如下图再新增一个哨兵节点，同时增加一个配置文件，由于默认端口为26379，上一个哨兵已经占用，这里在新增的配置文件中指定新哨兵的端口为：26388；

配置文件名为 sentinel26388.conf ，内容如下：

sentinel monitor mymaster 127.0.0.1 6388 1
port 26388

指定配置文件启动第二个哨兵，启动命令为 ./redis-sentinel ZoeConfig/sentinel26388.conf ，效果如下：

哨兵如何做到互相交流和监控从服务器的

到这应该有小伙伴会有疑问：在配置哨兵的时候，只配置监控主服务器，从服务器是怎么知道的？哨兵之间的交流是通过什么形式实现的？

关于从服务器：哨兵会自动询问主服务器获得对应从服务器的信息，因为从服务器会在连接主服务器的时候把相关信息给主服务器，所以哨兵能通过主服务器拿到从服务器的信息；

关于哨兵之间：哨兵节点会通过发布与订阅功能来自动发现正在监视 相同主服务器 的其他哨兵 ， 这一功能是通过向频道 sentinel :hello 发送信息来实现的；

注：一个哨兵可以同时监控多个主服务器；

哨兵配置文件介绍

以上配置只是为了快速实现演示，其实关于哨兵还有其他很多配置，接下来都过一遍：

• port：哨兵的端口，默认是26379，可以通过此配置项进行修改；
• dir：哨兵的工作目录；
• sentinel monitor ： 指定哨兵监控的主服务器；master-name：对监控的节点进行命名，方便后续根据名称获取信息；ip：主节点ip;redis-port：主节点的端口；quorum：整数，及设置有几个哨兵统一认为主节点下线为条件，满足这个数量就将主节点标记为客观下线；例：sentinel monitor mymaster 127.0.0.1 6388 2，意思就是当有两个哨兵都认为监控的mymaster主节点下线了，就将此主节点标记为客观下线；则可以进行下一步故障转移操作了；
• sentinel auth-pass ： 设置主节点和从节点的连接密码，这里只能统一设置，所以主节点和从节点的密码要一样；
• sentinel down-after-milliseconds ： 设置失联时间，单位为毫秒，默认为30秒，如果哨兵在30秒内没有接收到主节点的应答，就认为主节点异常了，并将其标记为主观下线；
• sentinel parallel-syncs ： 故障转移之后，在新的主从关系下，同时有多少个从节点向主节点要求进行数据同步； 默认设置是1，即一个一个同步，这样可以减少主节点同步压力；如果主节点机器性能允许，可以适当增加数量；
• sentinel failover-timeout ： 用于故障转移超时过程判断，默认设置为180000，即3分钟；
• sentinel notification-script ： 设置脚本路径； 哨兵有任何警告级别时间发生时都会执行这个脚本，可以通过该脚本实现邮件等信息通知；

连接哨兵常用的命令

• info sentinel：获取监控的主节点信息；
• sentinel masters：获取监控主节点的详细信息；
• sentinel master <监控时设置的名称>：上面我们指定的是mymaster，信息和上面类似；
• sentinel get-master-addr-by-name <监控时设置的名称>：根据指定的名称获取ip地址和端口信息，上面我们指定的名称是mymaster；
• sentinel is-master-down-by-addr：查看监控的主节点是否下线，哨兵之间判断主节点是否下线原理就是通过此命令；
• sentinel slaves <监控时设置的名称>：获取监控主节点的从节点信息；上面我们指定的是mymaster
• sentinel failover <监控时设置的名称>：该命令可以 强制对指定监控执行故障转移 ，即便当前的主节点运行完好也能执行；例如，需要换掉当前监控的主节点，便可以提前通过failover命令进行故障转移；上面我们指定的名称是mymaster；