Redis的持久化机制你学会了吗?

By | 2021年7月21日

大家都知道Redis经常被使用在缓存的场景中,那有没有想过这么一个问题,一旦服务器宕机,内存中的数据全部丢失,我们该如何进行恢复呢?如果直接从后端数据库恢复,不仅会给数据库带来巨大的压力,还会使上层应用响应变慢。所以redis的持久化机制是很重要的。接下来我们一起来探讨一下Redis的持久化机制。目前Redis持久化主要有两大机制,即AOF(Append Only File)日志和RDB快照。接下来我们就来分别学习一下。

 AOF日志

AOF日志,即写后日志,它的含义是Redis先执行命令,把数据写入内存,然后再写入日志。Redis为什么要先执行命令后写入日志呢?首先我们来看一下AOF日志里记录了什么内容。AOF记录的是Redis收到的每一条命令,这些日志以文本的形式保存。假如我们执行了set hello world命令,AOF的内容如下:

其中“*3”代表当前命令有3部分,每部分是由”$+数字”开头,后面紧跟着具体命令、键和值。这里的数字代表后面的命令、键和值一共有多少个字节。例如 “$3 set”表示这部分有3个字节,也就是“set”命令。

Redis为了避免额外的检查开销,再往AOF里写入日志的时候,并不会对这些命令进行语法检查。所以如果先写日志再执行命令,日志中就可能会记录一些错误的命令,Redis使用日志恢复的时候就会出错。而写后日志这种方式,就是先去执行命令,如果命令执行出错,则不写入日志,只有执行成功的命令才会写入日志中。所以Redis使用写后日志这一方式的一大好处是,可以避免出现记录错误命令的情况。AOF还有一大好处,它是在命令执行后才记录日志,所以不会阻塞当前的写操作。

不过,AOF也有潜在的两个风险,首先如果刚执行完一个命令,还没来的及写日志就宕机了,那么这个命令和相应的数据就有丢失的风险。其次,AOF虽然避免了对当前命令的阻塞,但可能会给下一个操作带来阻塞风险。这是因为,AOF日志也是在主线程中执行的,如何在把日志文件写入磁盘很慢时,就会阻塞后续操作。针对这个问题,AOF给我们提供了三种写回策略,也就是AOF的配置项appendfsync的三个可选值。

  1. Always,同步写回:每个写命令执行完,立马同步地将日志写回磁盘;
  2. Everysec,每秒写回:每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,每隔一秒把缓冲区中的内容写入磁盘;
  3. No,操作系统控制的写回:每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。

这三种写回策略都无法做到两全其美,都有自己的优缺点,我们只能根据我们的业务场景,是需要高性能还是高可靠性来选择不同的写回策略。

 

 

最后,AOF还有一个问题,就是AOF以文件的形式记录在磁盘里。随着Redis接受的写命令越来越多,那么AOF日志文件也会越来越大,所以需要采取一定的手段来控制AOF日志文件的大小。这个时候,AOF重写机制就派上用场了。AOF重写机制是指在重写时,Redis会根据数据库的现状创建一个新的AOF文件,也就是说,读取数据库中的所有键值对,然后对每一个键值对用一条命令记录它的写入。为什么重写机制可以把日志文件变小呢?实际上,重写机制具有“多变一”功能。所谓的“多变一”,也就是说,旧日志文件中的多条命令,在重写后的新日志中变成了一条命令。例如我们对某个key进行了6次写入操作,那么旧的日志文件中就会有6条记录,而重写后的日志文件中就只有一条命令,所以AOF重写会减小文件的大小。那么AOF重写会阻塞主线程吗?毕竟把整个Redis的数据库的最新数据的操作日志都写回磁盘,仍然是一个非常耗时的过程。和AOF日志由主线程写回不同,重写过程是由后台子进程bgrewriteaof来完成的,这也是为了避免阻塞主线程,导致Redis的性能下降。每次执行重写时,主线程 fork 出后台的 bgrewriteaof 子进程。此时,fork 会把主线程的内存拷贝(采用操作系统的写时复制技术,不会真正的拷贝,写时复制技术下面会分析)一份给 bgrewriteaof 子进程,这里面就包含了数据库的最新数据。然后,bgrewriteaof 子进程就可以在不影响主线程的情况下,逐一把拷贝的数据写成操作,记入重写日志。因为主线程未阻塞,仍然可以处理新来的操作。为了避免数据丢失,在AOF重写过程中,新进入的写命令会写入到两份日志中。第一处日志就正在使用的 AOF 日志,Redis 会把这个操作写到它的缓冲区。这样一来,即使宕机了,这个 AOF 日志的操作仍然是齐全的,可以用于恢复。第二处日志,就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这样,重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后,重写日志记录的这些最新操作也会写入新的 AOF 文件,以保证数据库最新状态的记录。此时,我们就可以用新的 AOF 文件替代旧文件了。

 

RDB快照文件 

      由于AOF记录的是操作命令,而不是实际的数据。所以,用AOF方法进行故障恢复的时候,需要逐一把操作日志都执行一遍。如果操作日志很多,那Redis恢复的就很慢,影响到正常使用。那有没有即保证可靠性,还能在宕机时实现快速的恢复办法呢?那就是内存快照。对于Redis来说,它把某一时刻的状态以文件的形式写到磁盘上。这样一来,即使宕机,快照文件也不会丢失,数据的可靠性得到了保证。这个快照文件就叫RDB(Redis DataBase)文件。和AOF相比,RDB记录的是某一时刻的数据,并不是操作,所以,在做数据恢复时,直接把RDB文件加载到内存里,很快的完成恢复。

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

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

所以,我们可以采用bgsave来执行全量快照,既保证了可靠性,又避免了Redis的性能影响。接下了,我们来思考这么一个问题,就是Redis在做全量快照时,Redis中的数据可以被修改吗?Redis还支持写操作吗?为了快照而暂停写操作,Redis肯定是不能接受的。所以Redis借助了操作系统提供的写时复制技术(Copy-On-Write,COW)。简单来说,bgsave子进程是由主线程fork生成的,可以共享主线程的所有内存数据。bgsave运行之后,开始读取主线程中的内存数据,并把他们写入RDB文件。此时,如果主线程对这些数据进行读操作,则主线程和bgsave子进程相互不影响。但是,如果主线程执行写操作或者修改操作,也就是修改内存中的一块数据,那么这块数据会复制一份,生成副本。然后主线程在副本上进行修改。同时,bgsave子进程继续把原来的数据写入RDB文件。这样既保证了快照的完整性,也避免了对正常业务的影响。

      接下来我们来看下一个问题,就是多久做一次快照,如果快照隔的时间太久,丢的数据就越多,间隔时间太短,丢失的数据越少,但是频繁的执行全量快照会给磁盘带来很大的压力。由于fork创建子进程bgsave这个过程是需要阻塞主线程的,主线程的内存越大,fork时间越长。所以频繁的fork出bgsave子进程,也就会频繁阻塞主线程。那有什么好的办法既能利用RDB的快速恢复,又能以较小的开销做到尽量少丢数据呢。Redis4.0提出了一个混合使用AOF日志和RDB的方法。简单来说,内存快照以一定的频率执行,两次快照之间使用AOF记录操作命令。

最后总结一下,关于AOF和RDB的选择问题,给大家提供3点建议。

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

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注