免费视频福利推荐:
2T学习视频教程+电子书 免费送:BAT面试精讲视频,亿级流量秒杀系统,分布式系统架构,中间件消息队列,Python Go入门到精通,Java实战项目,Linux, 网络,MySQL高性能,Redis集群架构,大数据,架构师速成,微服务,容器化Docker K8s, ELK Stack日志系统等免费视频教程!
欢迎关注公众号:「码农富哥」,致力于分享后端技术 (高并发架构,分布式集群系统,消息队列中间件,网络,微服务,Linux, TCP/IP, HTTP, MySQL, Redis), Python 等 原创干货 和 面试指南!
关注公众号后回复【资源】免费获取 2T 编程视频和电子书,回复【Redis】获取 Redis高可用集群架构视频
在介绍Redis高可用之前,先说明一下在Redis的语境中高可用的含义。
我们知道,在web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常服务(99.9%、99.99%、99.999% 等等)。但是在Redis语境中,高可用的含义似乎要宽泛一些,除了保证提供正常服务(如主从分离、快速容灾技术),还需要考虑数据容量的扩展、数据安全不会丢失等。
在Redis中,实现高可用的技术主要包括持久化、复制、哨兵和集群,下面分别说明它们的作用,以及解决了什么样的问题。
Redis 的数据全部在内存里,如果突然宕机,数据就会全部丢失,因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失,这种机制就是 Redis 的持久化机制。
Redis为持久化提供了两种方式:
由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式,不过RDB持久化仍然有其用武之地。
下面依次介绍RDB持久化和AOF持久化;
RDB是默认的持久化方式,按照一定的策略周期性的将内存中的数据生成快照保存到磁盘。
每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。
RDB触发持久化分为手动触发和自动触发
1. save 命令(手动触发)
当客户端向Redis server发送save命令请求进行持久化时,由于Redis是用一个主线程来处理所有,save命令会阻塞Redis server处理其他客户端的请求,直到数据同步完成。save命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在Redis服务器阻塞期间,服务器不能处理任何命令请求,因此线上环境不推荐使用
2. bgsave命令(手动触发)
与save命令不同,bgsave是异步执行的,当执行bgsave命令之后,Redis主进程会fork 一个子进程将数据保存到rdb文件中,同步完数据之后,对原有文件进行替换,然后通知主进程表示同步完成。
3. 自动触发
除了手动触发RDB持久化,Redis内部还存在自动触发机制,
在配置中集中配置 save m n 的方式,表示 m秒内数据集存在n次修改时,系统自动触发bgsave 操作。
# 时间策略
save 900 1
save 300 10
save 60 10000
# 文件名称
dbfilename dump.rdb
# 文件保存路径
dir /etc/redis/data/
# 如果持久化出错,主进程是否停止写入
stop-writes-on-bgsave-error yes
# 是否压缩
rdbcompression yes
# 导入时是否检查
rdbchecksum yes
rdb持久化策略比较简单,下面解释一下:
save 900 1
表示900s内如果有1条是写入命令,就触发产生一次快照,可以理解为就进行一次备份save 300 10
表示300s内有10条写入,就产生快照下面的类似,那么为什么需要配置这么多条规则呢?因为Redis每个时段的读写请求肯定不是均衡的,为了平衡性能与数据安全,我们可以自由定制什么情况下触发备份。所以这里就是根据自身Redis写入情况来进行合理配置。
stop-writes-on-bgsave-error yes
这个配置也是非常重要的一项配置,这是当备份进程出错时,主进程就停止接受新的写入操作,是为了保护持久化的数据一致性问题。如果自己的业务有完善的监控系统,可以禁止此项配置, 否则请开启。
rdbcompression yes
,用于配置是否压缩RDB文件,建议没有必要开启,毕竟Redis本身就属于CPU密集型服务器,再开启压缩会带来更多的CPU消耗,相比硬盘成本,CPU更值钱。
rdbchecksum yes:是否开启RDB文件的校验,在写入文件和读取文件时都起作用;关闭checksum在写入文件和启动文件时大约能带来10%的性能提升,但是数据损坏时无法发现
dbfilename dump.rdb:RDB文件名
dir ./:RDB文件和AOF文件所在目录
当然如果你想要禁用RDB配置,也是非常容易的,只需要在save的最后一行写上:save ""
1) Redis父进程首先判断:当前是否在执行save,或bgsave/bgrewriteaof(后面会详细介绍该命令)的子进程,如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行,主要是基于性能方面的考虑:两个并发的子进程同时执行大量的磁盘写操作,可能引起严重的性能问题。
2) 父进程执行fork操作创建子进程,这个过程中父进程是阻塞的,Redis不能执行来自客户端的任何命令
3) 父进程fork后,bgsave命令返回”Background saving started”信息并不再阻塞父进程,并可以响应其他命令
4) 子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换
5) 子进程发送信号给父进程表示完成,父进程更新统计信息
RDB文件的载入工作是在服务器启动时自动执行的,并没有专门的命令。但是由于AOF的优先级更高,因此当AOF开启时,Redis会优先载入AOF文件来恢复数据;
只有当AOF关闭时,才会在Redis服务器启动时检测RDB文件,并自动载入。服务器载入RDB文件期间处于阻塞状态,直到载入完成为止。
所以Redis的内存数据如果很大,会导致数据恢复时间比较长,因此线上实践更倾向于限制单个Redis的内存不能太大,同时结合Redis Cluster集群使用多节点部署
Redis启动日志中可以看到自动载入的执行:
Redis载入RDB文件时,会对RDB文件进行校验,如果文件损坏,则日志中会打印错误,Redis启动失败。
大家如果更系统了解Redis 高可用集群架构知识,可以关注公众号【码农富哥】后回复【Redis】获取 Redis高可用集群架构视频
RDB快照并不是很可靠。如果你的电脑突然宕机了,或者电源断了,又或者不小心杀掉了进程,那么最新的数据就会丢失。而AOF文件则提供了一种更为可靠的持久化方式。每当Redis接受到会修改数据集的命令时,就会把命令追加到AOF文件里,当你重启Redis时,AOF里的命令会被重新执行一次,重建数据。
由于需要记录Redis的每条写命令,因此AOF不需要触发, AOF的执行流程包括:
# 是否开启aof
appendonly yes
# 文件名称
appendfilename "appendonly.aof"
# 同步方式
appendfsync everysec
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加载aof时如果有错如何处理
aof-load-truncated yes
# 文件重写策略
aof-rewrite-incremental-fsync yes
同步步骤分为两步:
Redis写命令写入磁盘的命令是通过appendfsync来配置的。
appendfsync
三个取值代表三种落盘策略
:
随着写操作的不断增加,AOF文件会越来越大。例如你递增一个计数器100次,那么最终结果就是数据集里的计数器的值为最终的递增结果,但是AOF文件里却会把这100次操作完整的记录下来。而事实上要恢复这个记录,只需要1个命令就行了,也就是说AOF文件里那100条命令其实可以精简为1条。所以Redis支持这样一个功能:在不中断服务的情况下在后台重建AOF文件。
重写流程:
关于文件重写的流程,有两点需要特别注意:
(1)重写由父进程fork子进程进行;
(2)重写期间Redis执行的写命令,需要追加到新的AOF文件中,为此Redis引入了aof_rewrite_buf缓存。
对照上图,文件重写的流程如下:
1) Redis父进程首先判断当前是否存在正在执行 bgsave/bgrewriteaof的子进程,如果存在则bgrewriteaof命令直接返回,如果存在bgsave命令则等bgsave执行完成后再执行。前面曾介绍过,这个主要是基于性能方面的考虑。
2) 父进程执行fork操作创建子进程,这个过程中父进程是阻塞的。
3.1) 父进程fork后,bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程,并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区,并根据appendfsync策略同步到硬盘,保证原有AOF机制的正确。
3.2) 由于fork操作使用写时复制技术,子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令,因此Redis使用AOF重写缓冲区(图中的aof_rewrite_buf)保存这部分数据,防止新AOF文件生成期间丢失这部分数据。也就是说,bgrewriteaof执行期间,Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。
4) 子进程根据内存快照,按照命令合并规则写入到新的AOF文件。
5.1) 子进程写完新的AOF文件后,向父进程发信号,父进程更新统计信息,具体可以通过info persistence查看。
5.2) 父进程把AOF重写缓冲区的数据写入到新的AOF文件,这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
5.3) 使用新的AOF文件替换老文件,完成AOF重写。
重写触发:
1. 手动触发:直接调用bgrewriteaof命令,该命令的执行与bgsave有些类似:都是fork子进程进行具体的工作,且都只有在fork时阻塞。
2. 自动触发:通过配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size来完成
auto-aof-rewrite-percentage 100 :Redis会记住自从上一次重写后AOF文件的大小(如果自Redis启动后还没重写过,则记住启动时使用的AOF文件的大小)。如果当前的文件大小比起记住的那个大小超过指定的百分比,则会触配置发重写。
auto-aof-rewrite-min-size 64mb:同时需要设置一个文件大小最小值,只有大于这个值文件才会重写,以防文件很小,但是已经达到百分比的情况。
要禁用自动的日志重写功能,我们可以把百分比设置为0:
auto-aof-rewrite-percentage 0: 禁用日志重写功能
前面提到过,当AOF开启时,Redis启动时会优先载入AOF文件来恢复数据;
只有当AOF关闭时,才会载入RDB文件恢复数据。
当AOF开启,且AOF文件存在时,Redis启动日志:
RDB和AOF各有优缺点:
RDB持久化
优点:RDB文件紧凑,体积小,网络传输快,适合全量复制;恢复速度比AOF快很多。当然,与AOF相比,RDB最重要的优点之一是对性能的影响相对较小。
缺点:RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化,而在数据越来越重要的今天,数据的大量丢失很多时候是无法接受的,因此AOF持久化成为主流。此外,RDB文件需要满足特定格式,兼容性差(如老版本的Redis不兼容新版本的RDB文件)。
AOF持久化
与RDB持久化相对应,AOF的优点在于支持秒级持久化、兼容性好,缺点是文件大、恢复速度慢、对性能影响大。
通过上面的分析,我们都知道RDB的快照、AOF的重写都需要fork,这是一个重量级操作,会对Redis造成阻塞。因此为了不影响Redis主进程响应,我们需要尽可能降低阻塞。
在线上我们到底该怎么做?我提供一些自己的实践经验。
Redis的高可用系列:持久化就已经讲完了,持久化主要有RDB和AOF两种技术,大家按照上面所介绍的原理和流程,根据线上具体需求选择适合自己的持久化方案。
另外,写原创技术文章不易,要花费好多时间和精力,希望大家看到文章也能有所收获!你们的点赞和收藏就能成为我继续坚持输出原创文章的动力!大家也可以关注我的公众号,订阅更多我的文章!
欢迎关注公众号:「码农富哥」,致力于分享后端技术 (高并发架构,分布式集群系统,消息队列中间件,网络,微服务,Linux, TCP/IP, HTTP, MySQL, Redis), Python 等 原创干货 和 面试指南!
关注公众号后回复【资源】免费获取 2T 编程视频和电子书,回复【Redis】获取 Redis高可用集群架构视频