vlambda博客
学习文章列表

【Redis系列】论Redis主从模式及高可用的搭建

来都来了,不点个关注对的起你浪费的流量吗?

Redis作为一个单机性能优渥nosql类型的数据库,根据官网的性能测试报告,单机能达到55万的并发( 这个跟机器的配置有很大关系了),不过也能说明Redis性能之优渥了。放一张官网的图~

【Redis系列】论Redis主从模式及高可用的搭建

不过优秀归优秀,只要我们用户量够多,你单机就有不够用的时候,这时候就需要考虑集群的模式了,一般而言,用户量增长不快的情况下,可以使用主从模式暂时应付,将读写进行分离,从而提高Redis的利用效率。今天我们就来聊聊如何Redis的主从模式~

正文

Redis的主从模式

概念图解

主从模式是redis常用的集群部署方式,通常都是一主二从。
一主二从:

【Redis系列】论Redis主从模式及高可用的搭建

一主多从

【Redis系列】论Redis主从模式及高可用的搭建

主从原理

【Redis系列】论Redis主从模式及高可用的搭建

主从的原理:
在redis从节点上线后,会发送ping命令给主节点,这时候主节点会通过网络传输的方式将当前内存RDB文件发送到从节点所在的服务器上,从节点下载RDB文件,然后从自己硬盘上的RDB文件进行恢复数据,在恢复数据的过程中,如果主节点有数据写入,主节点会将写命令放在缓冲区,在从节点完成数据恢复后,主节点会将缓冲区中的数据发送给从节点,这样就保证了主从节点的数据一致性。
由于主节点只负责写命令,而从节点负责读命令,所以永远只会读到从节点的数据。

配置操作

下面的配置是我在manjaro(一个图形化桌面的linux系统) 先来瞧瞧搭建好后的成果图吧
查看下当前redis节点的replication信息
redis-cli上输入 info replication命令,下图可见当前redis节点的role是一个master,同时连在上面的从节点有一个。
主节点repliaction信息:

【Redis系列】论Redis主从模式及高可用的搭建

下图是从节点的一些信息,可以看出来当前redis节点的role是一个slave,同时master主节点的连接状态是up。
从节点replication信息:

【Redis系列】论Redis主从模式及高可用的搭建

华丽丽的分割线
上面是redis搭建好以后的信息,下面是搭建redis主从模式的步骤
修改从节点redis的redis.conf文件
搜索:replication,找到下图的位置。

【Redis系列】论Redis主从模式及高可用的搭建

添加上图的两行,分别代表主节点的ip/port 和 主节点的连接密码,配置完成后,当前从节点会自动像主节点进行注册连接。
一般而言,slave节点只允许读操作,不允许写操作,写操作只能从master节点,所以需要关闭slave节点的写操作权限(一般默认是关闭)。如下图:

【Redis系列】论Redis主从模式及高可用的搭建

配置完后重启slave节点redis,就成功了!!

Redis无磁盘化复制数据(功能在试验阶段)

一般而言,rerdis主从模式,slave节点同步master节点的数据是master节点通过网络把RDB文件传输到slave节点的硬盘上,然后slave节点再同步硬盘上的RDB文件。
由于数据的复制通过硬盘的IO操作了,可能由于硬盘只是普通的机械硬盘,速度相对而言会慢,所以redis又提供一种无磁盘化的复制方法,将RDB文件通过发送到slave节点socket上,不经过磁盘的持久化。
原理
master节点会创建一个子进程,在等待一定时间后(目的是等待slave节点连接上来)将RDB文件发送到slave节点的socket上。所以,redis配置文件中有两个配置项,一个是打开无磁盘化复制数据的功能开关,一个是配置发送等待时间的,如下图:

等待时长:单位是s

Redis 哨兵机制与实现

哨兵机制的作用

哨兵是一个独立的进程,用于监听redis集群中redis的存活状态, 是redis高可用的解决方案。一个哨兵可以监控多个master节点以及下面的slave节点,当master节点宕机后,所有的哨兵会通过选举机制,先选举出一个哨兵leader,有哨兵leader做故障转移,选举出一个新的master节点,保证集群的高可用性

哨兵机制的特性

  1. 选举机制:当一定数量(这个数量可配置)的哨兵认为master节点宕机后,哨兵集群就会选出一个哨兵leader,leader就会从剩余的slave节点中选举出一个新的master
  2. 当老的master节点恢复后,它会变成slave节点

配置哨兵

配置哨兵的数量一般会是奇数个,这样选举机制就是属于少数服从多数的策略
修改redis文件中的sentinel.conf文件
# 允许非哨兵进程所在本机访问哨兵protected-mode no# 哨兵进程占用的端口port 26379# 哨兵进程是否后台运行daemonize yes# 哨兵进程pid文件---存哨兵进程的进程id,默认就行,不用管它pidfile /var/run/redis-sentinel.pid# 哨兵日志文件地址logfile /usr/local/redis/log/sentinel.log# 哨兵进程工作空间dir /usr/local/redis-config/sentinel-working#哨兵监控的master节点信息 mymaster--master节点name(随便配)后面是ip+port,最后的数字代表当master宕机后,多少哨兵认为master宕机了,哨兵集群才统一认为master宕机sentinel monitor <mymaster> <127.0.0.1> <6379> <2># master节点name和密码sentinel auth-pass <mymaster> <password># 哨兵多久连不上master节点,认为节点宕机,默认30ssentinel down-after-milliseconds <mymaster> 30000# 选举出新master后,剩余slave节点同步master节点数据的并行度,1代表剩余slave节点一台一台同步数据sentinel parallel-syncs <mymaster> <1># 哨兵故障转移执行等待时间,默认3分钟,防止哨兵在故障转移时宕机,出现没有进行转移的问题sentinel failover-timeout <mymaster> <180000>
上面是实现哨兵需要配置一些配置项。 配置完成后记得将sentinel的工作空间文件夹创建下,不然启动哨兵会报错。
启动哨兵命令:
redis-sentinel <配置文件全路径>
tail -f <哨兵log全路径>---查看哨兵日志
测试:停掉master节点,查看哨兵日志

哨兵相关FAQ

1. master节点恢复成slave后,不同步新master的数据,master_link_status:down

1.原master节点redis.conf文件中未设置masterauth,导致master成为slave节点后,连不上新master节点
一般master数据无法同步给slave的方案检查为如下:
网络通信问题,要保证互相ping通,内网互通。
关闭防火墙,对应的端口开发(虚拟机中建议永久关闭防火墙,云服务器的话需要保证内网互通)。
统一所有的密码,master节点和slave节点密码一样,不要漏了某个节点没有设置。

部署约定

  1. 哨兵节点至少是3个或者奇数个
  2. 哨兵分布式部署在不同的计算机节点
  3. 一组哨兵只监听一组主从
    结束语
上面就是搭建Redis主从模式的相关配置,大家看完肯定会觉得简单,但是看十遍不如自己做一遍,在你动手的过程中,你会遇到各种各样的问题,在解决问题的同时加深自己的印象,最后才能记的牢固!
搭建过程中有什么问题,也欢迎给我留言吧!