跟我一起学Redis

跟我一起学Redis之加个哨兵让主从复制更加高可用

2021-01-18  本文已影响0人  Code综艺圈

前言

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

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

正文

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

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

哨兵模式搭建

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

image-20210114141345708

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

  1. 搭建主从复制环境,如上图所示,6377作为主服务器,6388和6399作为从服务器,这里是通过配置文件的形式修改,最终效果如下:

    image-20210114142426244
  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

    启动效果如下:

    image-20210114164300813

    如上图所示,Redis哨兵其实本质还是一个Redis节点,只是运行模式不一样而已;

  4. 哨兵模式运行起来,模拟主服务器宕机,这里直接将6377服务器shutdown, 注意看哨兵打印的日志:

    先将主服务器6377关掉,如下:

    image-20210114165824631

    由于哨兵定时对主服务器进行监控,如果在30秒内(默认30秒)发现主服务器无法正常通讯时,就开始进行投票选举原主服务器下的从服务器作为新主服务器,哨兵打印日志如下:

    image-20210114170909938

    大概流程如下图:

    image-20210115105820011

    哨兵最后的状态会持久化到指定的配置文件中,之前只是简单配置了一条监控语句,现在如下:

    image-20210115122612914
  5. 验证故障转移结果;

    光说6388变成了主服务器没证据,连上6388看看,同时再看看6399有没有换新主人,如下图:

    6388主从信息

    image-20210114171247927

    对应的配置文件中将之前的主从关系配置已经去掉了。

    6399主从信息

    image-20210114171516670

    对应的配置文件也已经改了,如下:

    image-20210114171713342

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

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

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

image-20210115111608936

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

哨兵集群高可用

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

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

配置文件名为sentinel26388.conf,内容如下:

sentinel monitor mymaster 127.0.0.1 6388 1
port 26388

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

image-20210115123029803

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

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

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

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

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

哨兵配置文件介绍

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

连接哨兵常用的命令

总结

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

一个被程序搞丑的帅小伙,关注"Code综艺圈",跟我一起学~~~

上一篇 下一篇

猜你喜欢

热点阅读