系列十三、Redis的哨兵机制

一、概述

        上一讲讲述了Redis的主从复制架构，它解决了单点故障数据冗余备份的问题，但是它有一个显著存在的问题，即：主节点对外提供服务，从节点仅仅用来同步主节点的数据，那么当某一时刻主节点宕机了，那么此时redis服务是无法对外提供服务的，基于此Redis的Sentinel机制应运而生！Sentinel（哨兵）是Redis的高可用解决方案，由一个或者多个Sentinel实例组成集群，可以监视任意多个主服务器，以及这些服务器下属的所有从服务器，并在被监视的主服务器下线或者宕机时，自动地将下线的主服务器属下的某个从服务器升级为新的主服务器。简单来说哨兵就是带有自动故障转移功能的主从架构。

二、原理

 

三、搭建哨兵模式

3.1、步骤

        （1）创建sentinel.conf

        在master的redis6379.conf同级目录创建 sentinel.conf 文件（名字绝对不能错！）

touch sentinel.conf

 

        （2）配置哨兵

        sentinel.conf文件中的内容如下：

        格式：sentinel monitor <被监控的数据库名字> <哨兵数量>，例如：

        注意事项：bind 0.0.0.0一定要配置，如果不配置bind的话，在springboot整合Redis哨兵时，将报无法连接的错误

sentinel monitor redisMasterServer 192.168.173.232 6379 1
bind 0.0.0.0

（3）启动哨兵测试

        注意事项：启动哨兵模式进行测试时，需保证主从复制架构是可用的

        观察日志发现，sentinel的默认端口是26379

 ./redis-sentinel /myconf/redis/master/sentinel.conf

（4）观察sentinel.conf文件的变化

很明显的可以观察到，sentinel.conf文件中除了第（2）步我们添加的配置外，又自动回写了部分配置，即图中红色框中的东西；

3.2、测试 

3.2.1、查看当前各个节点的角色信息

3.2.2、master节点设置值，slave节点get值

3.2.3、关闭主节点（模拟主节点宕机）

        关闭主节点（模拟宕机），观察哨兵控制台日志信息。注意事项：哨兵选举主节点的默认选举时间是15s

3.2.4、再次查看各个节点的角色信息 

3.2.5、6379节点重新启动后各节点的角色信息

思考：6379节点重新启动后，它的角色信息是什么？

答：从节点。类比明朝皇帝朱祁镇（正统），土木堡之变被俘，后被弟弟朱祁钰（景泰）接替，后来土木堡危机瓦解之后被救回宫内，但是不可能再任新的皇帝了（景泰不答应）。

3.2.3、8379节点设置值，6379 & 7379节点获取值

3.3、结论

        通过上述的测试，发现6379作为master节点宕机后，通过哨兵机制从原来master的slave节点中竞选出了新的节点作为master节点对外提供服务，原master节点重新恢复正常后，将作为新的master节点的一个从节点。

3.4、哨兵机制的优缺点

优点：

        哨兵机制解决了主从复制架构中，当主节点宕机时从节点对外提供服务的弊端，也即使用哨兵机制能够在主节点宕机时，能够自动地将从节点切换为主节点，对外提供服务。

缺点：

        （1）单节点并发压力大（因为只有一个master节点）；

        （2）单节点的内存和物理磁盘上限问题无法得到有效解决；