Redis核心技术与实战笔记3-Redis数据持久化

目录

默认情况下,我们重启redis之后数据就丢失了,那么Redis如何做数据的持久化,目前Reids的持久化主要有两大机制,即 AOF 日志和 RDB 快照。

AOF日志实现

AOF 日志 是Redis先执行命令,把数据写入内存,然后才记录日志。

BrCXZV.jpg

这里通过一个实际的例子来演示,通过客户端执行set name peanut 存一个name=peanut,然后看AOF文件中的内容:

1
2
3
4
5
6
7
8
9
[root@centos-7 redis]# cat appendonly.aof 
*3
$3
set
$4
name
$6
peanut
[root@centos-7 redis]# 

这里的*3 表示当前命令有三个部分,每部分都是“$+数字”开头,后面紧跟着的是具体的命令,“数字”表示这部分中的命令、键或值一共有多少字节。“$3 set”表示这部分有 3 个字节,也就是“set”命令。“$4 name” 表示设置的key的name有4个字节,“$6 peanut” 表示设置的值peanut有6个字节

Redis为了避免额外的开销,Redis在向AOF里面记录日志的时候并不会先去对这 些命令进行语法检查。所以,如果先记日志再执行命令的话,日志中就有可能记录了错误 的命令,Redis 在使用日志恢复数据时,就可能会出错。

而写后日志这种方式,就是先让系统执行命令,只有命令能执行成功,才会被记录到日志 中,否则,系统就会直接向客户端报错。所以,Redis 使用写后日志这一方式的一大好处 是,可以避免出现记录错误命令的情况。

AOF 还有一个好处:它是在命令执行后才记录日志,所以不会阻塞当前的写操 作。

当然AOF也是有风险的:

  • 如果刚执行完一个命令,还没有来得及记日志就宕机了,那么这个命令和相应的数 据就有丢失的风险。
  • AOF 虽然避免了对当前命令的阻塞,但可能会给下一个操作带来阻塞风险。

三种写回策略

  • AOF 机制给我们提供了三个选择,也就是 AOF 配置项 appendfsync 的三个可选值。
  • Always,同步写回:每个写命令执行完,立马同步地将日志写回磁盘; Everysec,每秒写回:每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲 区,每隔一秒把缓冲区中的内容写入磁盘;
  • No,操作系统控制的写回:每个写命令执行完,只是先把日志写到 AOF 文件的内存缓 冲区,由操作系统决定何时将缓冲区内容写回磁盘。

当然这三种写回策略都无法做到两全其美。关于三种写回的优缺点:

BrGD29.jpg

其实总结如下:

  • 想要获得高性能,就选择 No 策略;
  • 如果想要得到高可靠性保证,就选择 Always 策略;
  • 如果允许数据有一点丢失,又希望性能别受太大影响的话,那么就选择 Everysec 策略。

当然需要注意的是这里的AOF写回策略并不能完全解决问题,AOF 是以文 件的形式在记录接收到的所有写命令。随着接收的写命令越来越多,AOF 文件会越来越 大。这样就会造成如下问题:

  • 文件系统本身对文件大小有限制, 无法保存过大的文件
  • 如果文件太大,之后再往里面追加命令记录的话,效率也会 变低
  • 如果发生宕机,AOF 中记录的命令要一个个被重新执行,用于故障恢复,如 果日志文件太大,整个恢复过程就会非常缓慢

而AOF重写机制就是为了解决上面的这三个问题

AOF重写机制

关于日志文件太大问题解决 Redis 根据数据库的现状创建一个新的AOF文件,然后对每一个键值对用一条命令记录它的写入。 这样原本的日志文件可能对这个key的值进行了多次更改,这样就会记录多条命令追加在日志文件中,其实可以精简为一个set语句实现

但是这里会产生一个新的问题:要把整个数据库的最新数据的操作日志 都写回磁盘,仍然是一个非常耗时的过程。 不过好在Redis的重写过程是由后台线程 bgrewriteaof 来完成的,这也是为了避免阻塞主线程,导致数据库性能下降。

Bse1t1.jpg

RDB 内存快照

用 AOF 方法进行故障恢复 的时候,需要逐一把操作日志都执行一遍。如果操作日志非常多,Redis就会恢复得很缓 慢,影响到正常使用。所以Redis提供了另外一种方法实现快速恢复数据:内存快照

对 Redis 来说,它实现类似照片记录效果的方式,就是把某一时刻的状态以文件的形式写 到磁盘上,也就是快照。这样一来,即使宕机,快照文件也不会丢失,数据的可靠性也就 得到了保证。这个快照文件就称为 RDB 文件,其中,RDB 就是 Redis DataBase 的缩 写。

和 AOF 相比,RDB 记录的是某一时刻的数据,并不是操作,所以,在做数据恢复时,我 们可以直接把 RDB 文件读入内存,很快地完成恢复。

当然RDB 内存快照的方式也不是完美的,因为给内存的全量数据做快照, 把它们全部写入磁盘也会花费很多时间。而且,全量数据越多,RDB 文件就越大,往磁盘 上写数据的时间开销就越大。

Redis 提供了两个命令来生成 RDB 文件,分别是 save 和 bgsave。

  • save:在主线程中执行,会导致阻塞;
  • bgsave:创建一个子进程,专门用于写入 RDB 文件,避免了主线程的阻塞,这也是 Redis RDB 文件生成的默认配置。

这里需要注意: bgsave 避免阻 塞和正常处理写操作并不是一回事。此时,主线程的确没有阻塞,可以正常接收请求,但 是,为了保证快照完整性,它只能处理读操作,因为不能修改正在执行快照的数据。

为了快照而暂停写操作,肯定是不能接受的。所以这个时候,Redis 就会借助操作系统提 供的写时复制技术(Copy-On-Write, COW),在执行快照的同时,正常处理写操作。

bgsave 子进程是由主线程 fork 生成的,可以共享主线程的所有内存数据。 bgsave 子进程运行后,开始读取主线程的内存数据,并把它们写入 RDB 文件。

BsMeeS.jpg

如果主线程对这些数据也都是读操作(例如图中的键值对 A),那么,主线程和 bgsave 子进程相互不影响。但是,如果主线程要修改一块数据(例如图中的键值对 C), 那么,这块数据就会被复制一份,生成该数据的副本。然后,bgsave 子进程会把这个副本 数据写入 RDB 文件,而在这个过程中,主线程仍然可以直接修改原来的数据。

多久执行一次快照?

这里需要知道虽然 bgsave 执行时不阻塞主线程,但是,如果频繁地执行全量 快照,也会带来两方面的开销。主要有以下问题:

  • 频繁将全量数据写入磁盘,会给磁盘带来很大压力,多个快照竞争有限的磁盘带宽,前一个快照还没有做完,后一个又开始做了,容易造成恶性循环。
  • bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然,子进程在创建后 不会再阻塞主线程,但是,fork 这个创建过程本身会阻塞主线程,而且主线程的内存越 大,阻塞时间越长。如果频繁 fork 出 bgsave 子进程,这就会频繁阻塞主线程了。

增量快照

增量快照,所谓增量快照,就是指,做了一次全量快照后,后续的快照 只对修改的数据进行快照记录,这样可以避免每次全量快照的开销。

在第一次做完全量快照后,T1 和 T2 时刻如果再做快照,我们只需要将被修改的数据写入 快照文件就行。但是,这么做的前提是,我们需要记住哪些数据被修改了。你可不要小瞧 这个“记住”功能,它需要我们使用额外的元数据信息去记录哪些数据被修改了,这会带 来额外的空间开销问题。

虽然跟 AOF 相比,快照的恢复速度快,但是,快照的频率不好把 握,如果频率太低,两次快照间一旦宕机,就可能有比较多的数据丢失。如果频率太高, 又会产生额外开销,

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说,内存快照以一 定的频率执行,在两次快照之间,使用 AOF 日志记录这期间的所有命令操作。

快照不用很频繁地执行,这就避免了频繁 fork 对主线程的影响。而且,AOF 日志也只用记录两次快照间的操作,也就是说,不需要记录所有操作了,因此,就不会出 现文件过大的情况了,也可以避免重写开销。

BsQHjx.jpg

T1 和 T2 时刻的修改,用 AOF 日志记录,等到第二次做全量快照时,就可 以清空 AOF 日志,因为此时的修改都已经记录到快照中了,恢复时就不再用日志了。

小结

不管是AOF还是RDB 都各自有各自的优缺点,不过内存快照和 AOF 的混合使用似乎是一个非常不错的选择

  • 数据不能丢失时,内存快照和 AOF 的混合使用是一个很好的选择
  • 如果允许分钟级别的数据丢失,可以只使用 RDB
  • 如果只用 AOF,优先使用 everysec 的配置选项,因为它在可靠性和性能之间取了一个平衡。

面试题

使用一个 2 核 CPU、4GB 内存、500GB 磁盘的云主机运行 Redis,Redis 数据库的数据量大小差不多是 2GB,我们使用了 RDB 做持久化保证。当时 Redis 的运行负载以修改操作为主,写读比例差不多在 8:2 左右,也就是说,如果有 100 个请求,80 个请求执行的是修改操作。你觉得,在这个场景下,用 RDB 做持久化有什么风险吗?

一个网友非常不错的答案:

a、内存资源风险:Redis fork子进程做RDB持久化,由于写的比例为80%,那么在持久化过程中,“写实复制”会重新分配整个实例80%的内存副本,大约需要重新分配1.6GB内存空间,这样整个系统的内存使用接近饱和,如果此时父进程又有大量新key写入,很快机器内存就会被吃光,如果机器开启了Swap机制,那么Redis会有一部分数据被换到磁盘上,当Redis访问这部分在磁盘上的数据时,性能会急剧下降,已经达不到高性能的标准(可以理解为武功被废)。如果机器没有开启Swap,会直接触发OOM,父子进程会面临被系统kill掉的风险。

b、CPU资源风险:虽然子进程在做RDB持久化,但生成RDB快照过程会消耗大量的CPU资源,虽然Redis处理处理请求是单线程的,但Redis Server还有其他线程在后台工作,例如AOF每秒刷盘、异步关闭文件描述符这些操作。由于机器只有2核CPU,这也就意味着父进程占用了超过一半的CPU资源,此时子进程做RDB持久化,可能会产生CPU竞争,导致的结果就是父进程处理请求延迟增大,子进程生成RDB快照的时间也会变长,整个Redis Server性能下降。

c、另外,可以再延伸一下,老师的问题没有提到Redis进程是否绑定了CPU,如果绑定了CPU,那么子进程会继承父进程的CPU亲和性属性,子进程必然会与父进程争夺同一个CPU资源,整个Redis Server的性能必然会受到影响!所以如果Redis需要开启定时RDB和AOF重写,进程一定不要绑定CPU。

AOF 日志重写的时候,是由 bgrewriteaof 子进程来完成的,不用主线程参与,我们今天说的非阻塞也是指子进程的执行不阻塞主线程。但是,你觉得,这个重写过程有没有其他潜在的阻塞风险呢?如果有的话,会在哪里阻塞?

一个网友非常不错的答案: a、fork子进程,fork这个瞬间一定是会阻塞主线程的,fork采用操作系统提供的写实复制(Copy On Write)机制,就是为了避免一次性拷贝大量内存数据给子进程造成的长时间阻塞问题,但fork子进程需要拷贝进程必要的数据结构,其中有一项就是拷贝内存页表(虚拟内存和物理内存的映射索引表),这个拷贝过程会消耗大量CPU资源,拷贝完成之前整个进程是会阻塞的,阻塞时间取决于整个实例的内存大小,实例越大,内存页表越大,fork阻塞时间越久。拷贝内存页表完成后,子进程与父进程指向相同的内存地址空间,也就是说此时虽然产生了子进程,但是并没有申请与父进程相同的内存大小。那什么时候父子进程才会真正内存分离呢?“写实复制”顾名思义,就是在写发生时,才真正拷贝内存真正的数据,这个过程中,父进程也可能会产生阻塞的风险,就是下面介绍的场景。

b、fork出的子进程指向与父进程相同的内存地址空间,此时子进程就可以执行AOF重写,把内存中的所有数据写入到AOF文件中。但是此时父进程依旧是会有流量写入的,如果父进程操作的是一个已经存在的key,那么这个时候父进程就会真正拷贝这个key对应的内存数据,申请新的内存空间,这样逐渐地,父子进程内存数据开始分离,父子进程逐渐拥有各自独立的内存空间。因为内存分配是以页为单位进行分配的,默认4k,如果父进程此时操作的是一个bigkey,重新申请大块内存耗时会变长,可能会产阻塞风险。另外,如果操作系统开启了内存大页机制(Huge Page,页面大小2M),那么父进程申请内存时阻塞的概率将会大大提高,所以在Redis机器上需要关闭Huge Page机制。Redis每次fork生成RDB或AOF重写完成后,都可以在Redis log中看到父进程重新申请了多大的内存空间。