Redis哨兵架构搭建以及详解
前言
前面介绍了redis的主从架构模式,主从架构模式只能够帮redis分担读的压力,但是这个架构有一个非常致命的缺陷,一旦master节点挂掉了,整个集群将无法写入数据,这并不符合redis高可用架构的特点。
那么根据上文所提出的缺陷,redis是否有方法能够解决提出的缺陷呢?答案肯定是有的,那就是本文所要介绍的哨兵架构模式。
哨兵概述
主从架构是高可用架构的基石,哨兵架构是主从架构的升级版,主从架构master节点和slave节点是一开始就定好了,而在哨兵模式中,master节点是可以转移的,一旦发现当前mster节点宕机了,哨兵底层会通过选举算法,指定一个slave节点晋升为master,保证在任何情况下,都有master节点可以支持写操作,也间接性支持写和读的高可用了。
哨兵的作用
从上文中我们可以了解到,哨兵的作用之一:自动故障转移
谈到作用就知道哨兵在架构中都做了些什么事情
哨兵的几种作用
- 监控: 不断检查master和slave节点是否正常运行,检查主节点是否存活,主节点和从节点运行情况
- 通知:检测到节点出现问题时,向其他的哨兵节点和客户端发送通知,
- 自动故障转移:当检测到master节点宕机了,将会断开与master节点连接的所有slave节点,然后从slave节点中选举一个节点作为master节点,然后自动将其他的slave连接到最新的master节点,并告知客户端最新的服务器地址
搭建哨兵架构
准备工作
开始配置哨兵,因本地资源有限,只搭建了3台服务器,一台master服务器,两台slave服务器,因本文重点哨兵架构,所以redis如何安装和配置这里就不做多介绍了,所以这三台服务器的redis单机版我都已经安装好了,如果小伙伴还不清楚,或者说想更兼容本文搭建,可以参考我的另外一篇文章 "手把手教你如何在CentOS7环境下安装部署Redis"
主要注意的是,哨兵架构是基于主从架构演变的,如果有小伙伴还不清楚如何主从架构,可以参考我的另外一篇文章 "Redis主从架构的搭建"
sentinel.conf配置详解
进入redis目录,找到sentinel.conf配置文件
#进入目录cd /usr/local/software/redis-5.0.3
#查看redis所有文件ls
接下来看redis sentinel.conf配置文件
如上图,这样查看配置文件是不是很费劲,全都是注释
这里给大家提供一个命令来过滤掉这些无用的信息
cat sentinel.conf | grep -v '#' | grep -v '^$'
sentinel.conf配置详解
port 26379
哨兵sentinel实例运行的端口，默认26379
daemonize no
redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
pidfile /var/run/redis-sentinel.pid
当redis以守护进程方式运行时，redis默认会把pid写入/var/run/redis-sentinel.pid文件，可以通过pidfile指定
logfile ""
指定日志文件名
dir /tmp
存储哨兵的工作信息
sentinel monitor mymaster 127.0.0.1 6379 2
mymaster名字可以自定义，ip地址为master节点的地址 后边的 2 代表的是，如果有俩个哨兵判断这个主节点挂了那这个主节点就挂了，通常设置为哨兵个数一半加一。
只有当半数以上的slave节点认为master节点宕机了,才会进行选举master节点,否则不会进行选举,
sentinel down-after-milliseconds mymaster 30000
哨兵连接主节点多长时间没有响应就代表挂了。后边 30000 是毫秒，也就是 30 秒。
sentinel parallel-syncs mymaster 1
这个配置项是指在故障转移时，最多有多少个从节点对新的主节点进行同步,这个值越小完成故障转移的时间就越长，这个值越大就意味着越多的从节点因为同步数据而不可用,可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
sentinel failover-timeout mymaster 180000
1. 同一个sentinel对同一个master两次failover之间的间隔时间。
2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
3.当想要取消一个正在进行的failover所需要的时间。
4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了。
开始配置
配置哨兵非常so easy,我们只需要将三台服务器的sentinel.conf文件中的monitor和 daemonize 配置即可,其他配置我们均可用默认的。
monitor的配置:IP地址全部改为master节点的IP,端口不变,哨兵数量根据实际而来,我只有三台服务器,所以配置为2
daemonize的配置:我们设置为yes,将sentinel设置为后台运行
配置完成之后,我们分别启动三台服务器的redis服务和哨兵服务
#进入redis目录,启动服务./src/redis-server redis.conf./src/redis-sentinel sentinel.conf
#查看redis端口,检查是否正常启动ps -ef | grep redis
如上图,我的三台服务器的redis服务和哨兵都已正常启动完成了。
然后我们接着进入三台服务器的redis客户端,输入info命令,分别查看他们的节点信息,可以看到我图中所标记的,查看他们的role:分别为master和slave节点,且master节点也能够看到连接他的slave节点的ip地址,而且slave节点也能看到连接master节点的ip地址。
我们在master节点的客户端,输入插入几条数据,看从节点是否能够正确同步数据
如上图,现在是master写数据,slave节点是能够正确同步数据的,那么就能够证明主从架构现在是OK的了
验证哨兵架构
好,我们现在开始验证哨兵架构
#连接sentinel客户端./src/redis-cli -p 26379
#在各自服务的redis-sentinel客户端,输入命令,查看sentinel信息info sentinel
如上图,我们可以了解到,master节点地址是192.168.137.18,slave为2此时正有两个从节点,sentinel为3,三个哨兵服务。
另外,我们还可以通过另外一种方式进行验证哨兵架构,我们在启动哨兵服务的时候,哨兵就会进行选举,而每次哨兵选举的时候,都会在sentinel.conf文件末尾追加选举的master节点的信息
如上图,slave节点会追加当前选举的master节点,注意,最上方的两行数据,是当前slave节点信息
演示故障转移
哨兵的4个作用中，配置提供者和通知需要客户端的配合
首先,我们使用kill命令杀掉主节点
如果此时立即在哨兵节点中使用info Sentinel命令查看，会发现主节点还没有切换过来，因为哨兵发现主节点故障并转移，需要一段时间。
一段时间以后，再次在哨兵节点中执行info sentinel查看，发现主节点已经切换192.168.137.20:6379节点。
但是同时可以发现，哨兵节点认为新的主节点仍然有2个slave节点，这是因为哨兵在将192.168.137.20:6379切换成主节点的同时，将192.168.137.18:6379节点置为其从节点；虽然192.168.137.18:6379从节点已经挂掉，但是由于哨兵并不会对从节点进行客观下线，因此认为该从节点一直存在。当192.168.137.18:6379节点重新启动后，会自动变成192.168.137.20:6379节点的从节点。
我们验证一下,重启192.168.137.18:6379节点,可以看到192.168.137.18:6379节点成为了192.168.137.20 6379节点的从节点。
在故障转移阶段，哨兵和主从节点的配置文件都会被改写,我们再来看一下sentinel.conf文件的变化
总结
1.每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。
2.在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写
3.哨兵节点本质上是redis节点
我是黎明大大,我知道我没有惊世的才华，也没有超于凡人的能力，但毕竟我还有一个不屈服，敢于选择向命运冲锋的灵魂，和一个就是伤痕累累也要义无反顾走下去的心。
