前言

主从复制的实现在上一篇已经分享过，虽然主从复制本身的确让读写分离更加高效，但是对于整体高可用存在很大的劣势：当主节点宕机了之后还需要人为重新进行主从关系配置；这不是开玩笑嘛，这样人为干预，故障恢复不及时，损失就难免啦。谁维护谁不爽，睡个觉都提心吊胆。

找个哨兵站岗，专门用来监控主服务器，一旦有变故，哨兵自动处理，这样故障恢复及时且更加智能；接下来就来玩玩。

正文

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.conf    redis-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；

 

总结

主从复制加个哨兵看似很完美啦，但仔细想想，虽然读写分离分开了，但写还是单节点，如果写的并发量特别大怎么办，那肯定扛不住，所以这下集群该出山了，下一次聊聊 redis 集群。