文章目录
- 1. 单点Redis的问题
- 数据丢失问题
- 并发能力问题
- 故障恢复问题
- 存储能力问题
- 2. Redis持久化 -> 数据丢失问题
- RDB持久化
- linux单机安装Redis步骤
- RDB持久化与恢复示例
- RDB机制
- RDB配置示例
- RDB的fork原理
- 总结
- AOF持久化
- AOF配置示例
- AOF文件重写
- RDB与AOF对比
- 3. Redis主从 -> 并发能力问题
- 主从架构
- 搭建主从架构示例
- 集群架构
- 准备实例和配置
- 启动
- 开启主从关系
- 测试
- 主从数据同步原理
- 主从的全量同步原理
- 简述全量同步的流程
- 主从的增量同步原理
- 主从数据同步优化点
- 总结
- 4. Redis哨兵 -> 故障恢复问题
- 5. Redis分片集群 -> 存储能力问题
【redis学习篇】主从&哨兵&集群架构详解
1. 单点Redis的问题
数据丢失问题
Redis是内存存储,服务重启可能会丢失数据
并发能力问题
单节点Redis并发能力虽然不错,但也无法满足如618这样的高并发场景
故障恢复问题
如果Redis宕机,则服务不可用,需要一种自动的故障恢复手段
存储能力问题
Redis基于内存,单节点能存储的数据量难以满足海量数据需求
2. Redis持久化 -> 数据丢失问题
RDB持久化
RDB全称Redis Database Backup file
(Redis数据备份文件),也被叫做Redis数据快照
。简单来说就是把内存中的所有数据都记录到磁盘中
。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。
快照文件称为RDB文件,默认是保存在当前运行目录。
save
命令:由于redis是单线程执行的,使用此save命令时,主进程会阻塞其它的命令,而将数据持久化到磁盘的耗时比较久,等到save命令结束,主进程才能执行其它命令。不推荐使用此命令,它通常用在Redis停机时使用。
bgsave
命令:后台异步执行,它会开启子进程执行RDB,避免主进程收到影响,推荐使用该命令作RDB。
Redis停机时会自动执行一次RDB(通过redis-cli连接上redis服务之后,输入shutdown命令即可让redis服务停止或者在redis未开启以守护模式运行时通过ctrl+c停止运行时,会自动执行一次RDB)。
linux单机安装Redis步骤
首先需要安装Redis所需要的依赖:
yum install -y gcc tcl
然后将课前资料提供的Redis安装包上传到虚拟机的任意目录:
例如,我放到了/tmp目录:
解压缩:
tar -xvf redis-6.2.4.tar.gz
解压后:
进入redis目录:
cd redis-6.2.4
运行编译命令:
make && make install
如果没有出错,应该就安装成功了(redis的默认安装位置是/usr/local/bin,在此/usr/local/bin目录下有:redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件;同时在redis-6.2.4目录下有redis.conf和sentinel.conf配置文件;同时在redis-6.2.4目录下的是src目录中也有redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件)。
然后修改redis.conf文件中的一些配置:
# 绑定地址,默认是127.0.0.1,会导致只能在本地访问。修改为0.0.0.0则可以在任意IP访问
bind 0.0.0.0# 数据库数量,设置为1
databases 1
启动Redis:
redis-server redis.conf # 使用redis-server命令启动redis, 并指定配置文件; 其中redis-server命令可在任意目录下执行
停止redis服务:
redis-cli shutdown # 其中redis-cli命令可在任意目录下执行
RDB持久化与恢复示例
按照【单机安装Redis步骤】中的步骤安装好redis后:
- 在/usr/local/bin目录下有redis-server、redis-cli、redis-benchmark、redis-sentinel等可执行文件,并且
- 在/usr/local/redis6/redis6.2.4/src目录下也有这些可执行文件;
- 在/usr/local/redis6/redis6.2.4/src下有redis.conf和sentinel.conf配置文件。
(这里主要是说明安装情况)
在如上安装好redis之后,这里演示下在关闭redis服务时,redis会自动执行RDB的案例
现在切换/usr/local/redis6/redis-6.2.4目录下(不是必须在这个目录,在其它目录也可以执行redis-server命令)
使用redis-server ./redis.conf
命令,来指定对应的配置文件启动redis服务,redis开始接收连接
现在开启另外1个窗口,使用set num 123
来保存1条数据到redis内存中,然后发出shutdown的命令,让redis关闭服务,此时redis服务会自动做1次RDB操作,将内存中的数据持久化到dump.rdb文件中(此dump.rdb文件默认会生成在运行redis-server命令时所在的目录中,这里在/usr/local/redis6/redis-6.2.4目录下)
现在/usr/local/redis6/redis-6.2.4目录下,继续在重新启动redis服务,查看前面通过RDB持久化的文件是否恢复到内存当中(这里就没有指定redis.conf了,也可以指定对应的配置文件)
在另外1个窗口,使用redis-cli连接上redis服务,查看数据,发现数据没有丢失,说明redis能够从持久化的文件恢复到内存中
RDB机制
上面案例演示了在redis服务关闭时,会自动执行RDB命令,将内存中的数据持久化到磁盘中。但是,假设redis运行过程中,突然宕机了,此时还没持久化到磁盘中,那么在存储在redis内存中的数据将会全部丢失,所以redis应该要有一套自动持久化的机制。
Redis内部有触发RDB的机制,可以在redis.conf文件中找到(这3个配置默认是被注释的,默认情况下RDB是开启的),格式如下:
RDB的其它配置也可以在redis.conf文件中设置:
(配置的含义就是 在指定的一段时间内,有指定数量的key被修改了,那么就执行1次RDB操作,将内存中的数据持久化到指定的目录下的指定的文件中。当然,redis启动时,也会从这个指定的目录下查找这个指定的文件加载到内存中。)
当有了RDB后,即使不关闭redis服务,也能通过配置将redis内存中的数据持久化到磁盘上,但是它会每隔一段时间,才会执行RDB操作。如果在某段时间内,尚未执行RDB时,此时宕机了,那么这段时间内的数据就丢失了。所以,可能会想着把间隔时间设置的尽可能短,但如果间隔时间很短,执行RDB的操作就太频繁了,影响redis的性能。所以使用默认的就好了。
RDB配置示例
说明:5s内,如果有1个key发生变化,那么持久化内存钟的数据到指定的文件中。其中,修改redis.conf文件部分如下:
# 5s内,如果有1个key发生变化, 则触发1次RDB持久化(如果需要禁用RDB, 则配置: save "" 即可)
save 5 1# 指定持久化文件的名字
dbfilename test.data # 指定RDB持久化文件的所在目录
dir ./my_data_dir
在/usr/local/redis6/redis-6.2.4下创建rdb_test目录,并在此rdb_test目录下创建my_data_dir文件夹用于存放持久化文件。修改号redis.conf配置文件后,使用该配置文件启动redis。
redis启动后,使用redis-cli连接上redis服务,并向redis中存储2条数据,然后观察redis服务的控制台上观察输出,看到了redis执行持久化的日志,关闭redis后,查看my_data_dir文件夹,看到了test.data数据持久化文件
再次使用指定的配置文件,启动redis,使用redis-cli再次查询数据,发现数据已恢复
RDB的fork原理
bgsave开始时会fork主进程得到子进程,子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。(bgsave是异步执行持久化的,对主进程几乎零阻塞,零阻塞的原因在于主进程在执行fork得到子进程时,此fork操作会阻塞,此时无法处理客户端请求)
fork采用的是copy-on-write技术:
- 当主进程执行读操作时,访问共享内存;
- 当主进程执行写操作时,则会拷贝一份数据,执行写操作(当此时针对很多key写操作时,就相当于要拷贝大量数据作为副本,此时就需要事先考虑给redis预留足够的空间)
总结
RDB方式bgsave的基本流程?
- fork主进程得到一个子进程,共享内存空间
- 子进程读取内存数据并异步写入新的RDB文件
- 用新RDB文件替换旧的RDB文件。
RDB会在什么时候执行?save 60 1000代表什么含义?
- 默认是服务停止时。
- 代表60秒内至少执行1000次修改则触发RDB
RDB的缺点?
- RDB执行间隔时间长,两次RDB之间写入数据有丢失的风险
- fork子进程、压缩、写出RDB文件都比较耗时
AOF持久化
AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件。
AOF默认是关闭的
,需要修改redis.conf配置文件来开启AOF:
AOF的命令记录的频率也可以通过redis.conf文件来配:
配置项 | 刷盘时机 | 优点 | 缺点 |
---|---|---|---|
Always | 同步刷盘(redis接收到命令后,使用命令操作完内存后,把此命令写到AOF文件磁盘中,此时主进程是阻塞的,等到写完AOF才返回给用户,主进程再处理其它请求) | 可靠性高,几乎不丢数据 | 性能影响大 |
everysec | 每秒刷盘(redis接收到命令后,使用命令操作完内存后,把此命令写到内存缓冲区中,写完缓冲区后,主进程立即返回。1s后再通过异步的方式将缓冲区中的数据写到AOF文件磁盘中,因为主进程是面对内存缓冲区中的读写,所以效率高,但是如果在写入的过程中宕机了,那么就会丢失这1s内的所有操作。它是默认方案。) | 性能适中 | 最多丢失1秒数据 |
no | 操作系统控制(由操作系统决定,可能频率会比较低) | 性能最好 | 可靠性较差,可能丢失大量数据 |
AOF配置示例
说明:AOF会记录每条执行的redis命令到aof文件中,这里关闭了rdb机制,开启了aof机制
# 关闭RDB机制
save ""# aof文件将会保存在此目录, 启动时会读取该目录下的aof文件(与RDB持久化文件所保存的目录相同)
dir ./aof_data_dir# 开启aof
appendonly yes# aof文件名
appendfilename "my_aof.data"# aof刷盘策略, 默认就是everysec, 不需要修改
appendfsync everysec
在/usr/local/redis6/redis-6.2.4下创建aof_test目录,并在此aof_test目录下创建aof_data_dir文件夹用于存放aof文件。修改好redis.conf配置文件后,使用该配置文件启动redis。
使用redis-cli客户端连接上redis服务,并且保存1条数据,然后退出redis-cli客户端,就可以在指定的目录下看到保存的aof文件了,并且这里看到了aof文件的内容,aof文件确实记录了每条redis命令
关闭redis时,redis也会执行1次aof
重新启动redis服务,会自动加载aof文件,然后使用redis-cli客户端连接上redis服务,查询redis服务关闭之前所保存的数据,能够查询到,说明aof文件被加载了
AOF文件重写
因为是记录命令,AOF文件会比RDB文件大的多
。而且AOF会记录对同一个key的多次写操作,但只有最后一次写操作才有意义。通过执行bgrewriteaof
命令,可以让AOF文件执行重写功能,用最少的命令达到相同效果(此命令为异步执行,他会让aof文件变小,并对内容作编码处理)。
Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置:
RDB与AOF对比
RDB和AOF各有自己的优缺点,如果对数据安全性要求较高,在实际开发中往往会结合两者
来使用。
特点 | RDB | AOF |
---|---|---|
持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
数据完整性 | 不完整,两次备份之间会丢失 | 相对完整,取决于刷盘策略 |
文件大小 | 会有压缩,文件体积小 | 记录命令,文件体积很大 |
宕机恢复速度 | 很快 | 慢 |
数据恢复优先级 | 低,因为数据完整性不如AOF | 高,因为数据完整性更高 |
系统资源占用 | 高,大量CPU和内存消耗 | 低,主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源 |
使用场景 | 可以容忍数分钟的数据丢失,追求更快的启动速度 | 对数据安全性要求较高常见 |
-
RDB与AOF数据恢复优先级:当目录下同时存在AOF与RDB文件时,会优先使用AOF文件来恢复数据,因为AOF文件数据更加完整,而RDB会丢失从上次备份的数据后到发生故障时这段时间内的数据。所以RDB更适合作为一种数据备份的手段。
-
AOF操作是异步的
3. Redis主从 -> 并发能力问题
主从架构
单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群
(而不是负载均衡的那种集群),实现读写分离
(因为redis查询操作多,增删改比较少,所以需要更多的处理读的压力,实现读写分离,提高读的并发能力)。
搭建主从架构示例
集群架构
我们搭建的主从集群结构如图:
共包含三个节点,一个主节点,两个从节点。这里我们会在同一台虚拟机中开启3个redis实例,模拟主从集群,信息如下:
IP | PORT | 角色 |
---|---|---|
172.17.23.234 | 7001 | master |
172.17.23.234 | 7002 | slave |
172.17.23.234 | 7003 | slave |
准备实例和配置
要在同一台虚拟机开启3个实例,必须准备三份不同的配置文件和目录,配置文件所在目录也就是工作目录。
1)创建目录
我们在/usr/local/redis6/redis-6.2.4/master-slave-cluster目录下,创建三个文件夹,名字分别叫redis7001、redis7002、redis7003,和1个最初的redis.conf配置文件(未作任何修改)
修改redis.conf配置文件:将其中的持久化模式改为默认的RDB模式,AOF保持关闭状态;配置bind允许远程连接;虚拟机本身有多个IP,为了避免将来混乱,我们需要在redis.conf文件中指定每一个实例的绑定ip信息。然后,将此redis.conf分别拷贝到redis7001、redis7002、redis7003中,然后分别修改他们对应的端口为:7001,7002,7003。
# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000# 关闭AOF
appendonly no# 允许远程连接(不设置此配置, 会无法同步)
bind 0.0.0.0# 虚拟机本身有多个IP,为了避免将来混乱,我们需要在redis.conf文件中指定每一个实例的绑定ip信息
replica-announce-ip 172.17.23.234# 这个目录在本示例中为了方便就不改了, 但是注意启动的时候, 需要到对应的目录下去启动, 否则rdb生成的文件会在redis-server的运行目录下
dir ./# 端口: redis7001、redis7002、redis7003中,然后分别修改他们对应的端口为:7001,7002,7003
port 7001 # 这里以7001为例
启动
分别在redis7001目录下启动7001,redis7002目录下7002,redis7003目录下7003(注意运行redis-server命令的目录,因为我们的dir配置的是./)
开启主从关系
现在三个实例还没有任何关系,要配置主从可以使用replicaof 或者slaveof(5.0以前)命令。
有临时和永久两种模式:
-
修改配置文件(永久生效)
- 在redis.conf中添加一行配置:
slaveof <masterip> <masterport>
- 在redis.conf中添加一行配置:
-
使用redis-cli客户端连接到redis服务,执行slaveof命令(重启后失效):
slaveof <masterip> <masterport>
注意:在5.0以后新增命令replicaof,与salveof效果一致。
这里让7002成为7001的slave,即让7002成为7001的从节点,执行该命令后,就会把7001主节点的数据同步过来
让7003成为7001的slave,并且从节点只能读取数据,不能够写入数据,只有主节点才能写入数据
测试
在主节点中写入数据,再分别从7002、7003从节点中读取到了数据,证明主从数据同步成功了。可以执行info replication
查看集群状态。
主从数据同步原理
主从的全量同步原理
主从第一次同步是全量复制
master如何判断slave是不是第一次来同步数据?这里会用到两个很重要的概念:
Replication Id
:简称replid,是数据集的标记,id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replidoffset
:偏移量,随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset,说明slave数据落后于master,需要更新。
因此slave做数据同步,必须向master声明自己的replication id
和offset
,master才可以判断到底需要同步哪些数据
全量同步过程
:从节点将自己的replication id发给主节点,主节点判断此replication id是否与自己的replication id是否一致,如果replication id不一致,说明该从节点是第一次来,主节点需要执行bgsave命令来做RDB保存起来,然后将自己的全量数据和offset同步到该从节点;如果replication id一致,说明从节点之前已经来过了,做过了全量同步了,并且从节点将offset也发过来了,因此主节点就可以从offset得知从节点的同步进度,因此主节点就将offset后面的数据发过去给从节点)
简述全量同步的流程
-
第1步:slave与master建立连接
-
第2步:slave节点请求增量同步
-
第3步:master节点判断replid,发现不一致,拒绝增量同步
-
第4步:master将完整内存数据生成RDB,发送RDB到slave
-
第5步:slave清空本地数据,加载master的RDB
-
第6步:master将RDB期间的命令记录在repl_baklog,并持续将log中的命令发送给slave
-
第7步:slave执行接收到的命令,保持与master之间的同步
主从的增量同步原理
主从第一次同步是全量同步
,,但如果slave重启后同步,则执行增量同步
。
增量同步过程:从节点重启后,依然需要携带自己的replid和offset向主节点请求同步数据,主节点收到该节点发过来的replid后,与自己的replid比较,发现一致,说明不是第一次来同步的,因此,就查看该节点发过来的offset查看该节点之前的同步进度,然后从repl_baklog中读取大于此offset的命令发送给从节点去同步。如果主节点这边检测到该未同步的数据已经被覆盖了,那么就会要求该节点做全量同步。
repl_baklog大小有上限,写满后会覆盖最早的数据。如果slave断开时间过久,导致尚未备份的数据被覆盖,则无法基于log做增量同步,此时只能再次全量同步。
主从数据同步优化点
可以从以下几个方面来优化Redis主从就集群:
-
在master中配置repl-diskless-sync yes启用无磁盘复制,避免全量同步时的磁盘IO(需要网络带宽足够大)。
-
Redis单节点上的内存占用不要太大,减少RDB导致的过多磁盘IO
-
适当提高repl_baklog的大小,发现slave宕机时尽快实现故障恢复,尽可能避免全量同步
-
限制一个master上的slave节点数量,如果实在是太多slave,则可以采用主-从-从链式结构,减少master压力
总结
简述全量同步和增量同步区别?
- 全量同步:master将完整内存数据生成RDB,发送RDB到slave。后续命令则记录在repl_baklog,逐个发送给slave。
- 增量同步:slave提交自己的offset到master,master获取repl_baklog中从offset之后的命令给slave
什么时候执行全量同步?
- slave节点第一次连接master节点时
- slave节点断开时间太久,repl_baklog中的offset已经被覆盖时
什么时候执行增量同步?
- slave节点断开又恢复,并且在repl_baklog中能找到offset时