深入剖析Redis持久化机制

以你之姓@ 2022-12-21 06:00 125阅读 0赞

**Redis持久化的意义**

Redis持久化的意义，主要体现在灾难恢复方面，即在Redis突然宕机重启后，能够快速恢复数据并对外提供服务。

在学习Redis的时候，大家都知道是用来作为缓存，而缓存，普遍思维都是认为，用来存储经常读取但是变化频次比较低的数据，这类数据通常不会很多，比如一些数据字典等，即使Redis服务宕机，大概率情况下不需要从持久化文件恢复。而一般的处理思维是，服务读取数据时，如果未在缓存中命中，那么直接读数据库（如MySQL），读到数据后返回给客户的同时，在Redis重新存储一份。下次读取时就可以在Redis缓存中拿到数据。这是一种通常的做法，同时这类场景，使用Redis持久化的意义不大。

但是在一些大型电商平台中，对于一些热门商品，一般情况下，其详细页的访问非常频繁，商品详细数据的读取频次非常的高，而且大型电商平台，这种类型的商品信息非常多，商品数据非常庞大。一般情况下，为了提高详细页面的吞吐量，商品信息基本都会使用缓存来缓存这些商品信息，用户访问时直接读缓存。在这类应用当中，Redis持久化的意义就非常的大。因为热门品类的商品，在大电商系统中，热门商品数据过亿条，这是很常见的事情，如果某一时刻，Redis缓存服务突然宕机，没有一个快速的恢复策略，那将是一个大灾难。因为上亿条的数据，如果一旦丢失就直接从数据库读取（缓存雪崩），数据库压力会非常非常大，大量的数据请求，会把数据库拖垮。

而Redis缓存数据持久化后，在Redis服务重启时，会自动从持久化文件快速恢复数据，大大降低了因为缓存数据丢失带来的灾难，这就是Redis持久化的意义所在。

Redis提供了两种持久化机制，分别是RDB和AOF，接下来介绍一下这两种持久化机制。

**RDB机制**

RDB数据持久化机制，是指Redis在指定时间点，会自动生成Redis内存中的数据的一份完整快照。  
![RDB持久化流程图][RDB]

RDB持久化的规则为：`save [time] [keys]`

*  表示每隔\[time\]秒，检查是否有\[keys\]个key发生变化，如果满足条件，Redis会fork一个子进程，将Redis内存中的数据进行全量的持久化，生成一个dump.rdb文件。

如上图，我们配置：`save 300 10`,每隔5分钟，检查是否有大于等于10个Key发生变化，如果有，则持久化数据到rdb文件。

比如第一个5分钟写入1000条数据，生成的dump.rdb文件中，就存在1000条数据，再隔5分钟，又写入1000条数据，再次持久化数据时，生成的dump.rdb文件中就有2000条数据。

RDB文件存储的数据，直接是Redis数据文件，在恢复数据时，直接将.rdb文件的数据加载到Redis内存数据库即可，恢复速度非常快。

**AOF机制**

AOF，即Append Only File的意思，就是说Redis一旦开启这种持久化机制，那么数据持久化时就会生成一个.aof的文件，而且持久化的数据时只会采取Append Only的模式向这个文件中不停的追加数据。

与RDB直接存储内存数据不同的是，AOF文件中持久化的是一系列的数据写入指令。Redis开启AOF持久化模式后，只要有数据写入Redis，都会按照一定的规则将写入指令按照Redis中写aof文件的指令规则将写入指令追加到aof文件中。

在Redis中，默认AOF持久化机制是关闭的，要打开需要做一些配置。在redis的配置文件中进行如下一些配置，即可开启AOF持久化机制。

#开启aof持久化模式
    appendonly yes
    #设置aof文件的名字为appendonly.aof
    appendfilename "appendonly.aof"
    #appendfsync 有三个选项分别为always/everysec/no，推荐设置为everysec，下文会详述区别
    appendfsync everysec
    #当前aof文件大小与上一次rewrite时aof文件大小的比例
    auto-aof-rewrite-percentage 100
    #当前aof文件大小
    auto-aof-rewrite-min-size 64mb

AOF持久化模式开启后，Redis持久化流程图如下：

![AOF持久化机制流程图][AOF]

在解读Redis持久化数据到aof文件的流程之前，先解释一下`appendfsync`三个选项值`always/everysec/no`所表达的意思。

*  appendfsync always ：表示每写入一条数据到Redis，Redis就会立即触发数据持久化操作，将这条数据的写指令追加到aof文件，选择这种配置，数据持久化aof文件，基本不会丢失数据，但是开启这种模式，Redis服务的性能会大大降低，因为每写入一条数据，就会触发一次落盘的IO操作，对性能的影响可想而知。
 *  appendfsync everysec：表示数据写入Redis之后，并不立即触发持久化操作，而是将数据的写指令先写一份到OS Cache中，每隔一秒触发一次持久化操作，持久化数据到aof文件时直接从OS Cache将缓存的数据写指令追加到aof文件。一般推荐采用该模式。
 *  appendfsync no：表示数据写入Redis之后，Redis将数据写入指令缓存到OS Cache后，就不管了，至于何时数据会从OS Cache持久化到aof文件，完全不受控制。

***下面我们解读一下Redis AOF持久化的步骤（基于appendfsync everysec）：***

1.  数据写入Redis；
2.  Redis将数据写入OS Cache；
3.  Redis判断当前aof文件大小是否超过上一次Rewrite时aof文件大小的一定比例（auto-aof-rewrite-percentage的值，上文设置为100，表示当前aof文件的大小是否是上一次Rewrite时的1倍），当前aof文件的大小是否超过最小值（auto-aof-rewrite-min-size设置的值，上文设置的64M），如果这两个条件同时满足，则触发Rewrite流程；（与步骤4无先后）
4.  每隔一秒，Redis将OS Cache中的数据写指令自动追加到aof文件，完成持久化；（与步骤3无先后）；

***aof文件Rewrite流程：***

1.  Redis先Fork一个子进程，生成一个临时aof文件，基于当前内存中的数据，将这些数据的写指令写入这个临时aof文件；
2.  子进程完成数据持久化之后，会通知Redis，Redis会自动将新写入OS Cache的数据写指令追加到临时aof文件中，保证新的aof文件数据的完整性；
3.  使用临时aof文件替换旧的aof文件；

***AOF文件Rewrite存在的意义，主要是因为：***

1.  aof文件是一个不停往文件末尾追加写指令的文件，久而久之，这个文件会变得非常非常的大；
2.  Redis是一个内存数据库，计算机的内存是有限的，当写入的数据量很多时，Redis会基于LRU算法将最近最少使用的数据进行淘汰，然而对于数据持久化来说，我们也只需要持久化当前内存中的数据就行，对于Redis基于它本身的算法，已经淘汰的数据，我们再进行持久化已经意义不大。
3.  aof文件记录的是Redis中数据的写入指令，基于该文件恢复数据时，如果文件太大，恢复速度会相对较慢。被淘汰的数据在aof文件中，保存了这些数据的添加和删除指令，如果不进行Rewrite，那么进行数据恢复时，会执行很多已经淘汰了的数据的添加和删除指令，严重影响实际有效数据恢复的速度。

**AOF和RDB比较**

***RDB优点：***

1.  RDB机制，是指每隔指定的时间段，对Redis内存中的数据进行一次全量备份，生成一份数据快照，非常适合做数据冷备。
2.  RDB存储的就是一份Redis数据文件，在数据恢复时，直接将rdb文件中的数据加载到内存即可，在大数据量的情况下，rdb的回复速度比从aof文件中恢复数据要快。
3.  基于RDB机制，进行数据持久化时，是由Redis Fork一个子进程来进行数据的持久化，在持久化的时候，完全由子进程来完成持久化工作，这样就可以极大的避免服务进程执行IO操作。
4.  相同的数据量，RDB机制生成的数据快照文件要比基于AOF机制生成的数据日志文件要小。

***RDB缺点：***

1.  因为RDB是每隔一段时间进行一次数据持久化，那么在持久化执行之前Redis服务宕机，就会造成最近的一个时间段内的数据丢失。比如5分钟进行一次持久化，上一次持久化之后不到5分钟，Redis服务宕机了，那么上一次持久化之后写入Redis的数据就丢失了。
2.  由于RDB是Fork一个子进程来协助完成数据持久化的，因此，如果将数据集太大时，可能会导致整个服务器停止服务几百毫秒甚至数秒。

***AOF优点：***

1.  相对RDB机制，AOF数据持久化机制，可以更好的减少数据的丢失，“appendfsync everysec”配置下，极端情况下，也只会丢失一秒钟的数据。也真是因为这个特性，当Redis启用RDB和AOF两种数据持久化机制时，Redis会优先基于aof文件进行数据恢复。
2.  AOF持久化文件是以append only的模式写入，直接在aof文件末尾追加写指令，没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复（基于redis-check-aof工具，可以快速修复aof破损文件）。
3.  如果aof文件过大，Redis会自动启动Rewrite流程，基于当前Redis内存中的数据进行aof文件的重写。
4.  AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。

***AOF缺点：***

1.  相同的数据量，AOF机制下生成的持久化文件要比基于RDB机制生成的持久化文件要大。
2.  相同的数据量，数据恢复时，从基于AOF机制下生成的aof日志文件恢复数据要比从基于RDB机制下生成的rdb文件恢复要慢。
3.  AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。

***推荐使用：***

一般情况下，推荐同时开启RDB和AOF两种机制对数据进行持久化，用AOF来保证数据不丢失，作为数据恢复的第一选择。用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

**Redis故障后数据恢复步骤**

这里主要讲基于RDB数据快照恢复数据时的步骤，因为基于aof文件恢复数据，只需要将aof文件拷贝到数据持久化的目录，启动Redis服务即可，但是基于rdb快照恢复数据，因为同时开启RDB和AOF机制，开启AOF模式从rdb快照恢复数据，在aof问空的情况下，恢复数据会失败。

1.  将redis配置文件中的appendonly先设置为no，因为不进行这一步设置，启动Redis服务时，Redis会优先从aof文件进行数据恢复，如果appendonly先设置为yes，Redis服务启动时，Redis发现持久化目录没有.aof文件，会自动生成一个空的.aof文件，那么就不会从.rdb文件恢复数据。
2.  将持久化的.rdb文件拷贝到Redis的数据持久化目录。
3.  启动Redis服务；
4.  使用Redis客户端工具（redis-cli）连接到Redis Server，使用config appendonly yes命令，热启动AOF机制，执行这一步的原因是，Redis启动的时候，已经从.rdb文件将数据恢复到Redis内存中，但是因为我们第一步配置的appendonly为no，所以Redis不会启动基于AOF持久化机制，因此我们要通过命令启动，将数据持久化到AOF文件中，这样我们才能够在修改了配置文件，将appendonly先设置为yes之后，重新启动Redis服务时正常恢复数据。
5.  等到AOF数据持久化完毕之后，停掉Redis服务，修改配置文件，将appendonly的值改回yes。
6.  重启Redis服务，Redis自动从.aof文件恢复数据。
7.  基于.rdb快照的数据恢复完成。

**Redis 4.x版本中的混合持久化**

从Redis的4.0版本开始，就增加了混合持久化的功能，5.0版本默认是关闭的，5.0之后默认是打开的。关闭和打开主要通过配置aof-use-rdb-preamble来实现，改配置为yes，表示打开混合持久化，配置为no表示关闭混合持久化。

混合持久化，主要是在AOF持久化过程中，触发AOF Rewrite的时候发挥关键作用。

当开启混合持久化的功能时触发AOF的Rewrite事件，Redis Fork出的子进程，不再像4.0版本以前那样，将当前内存中的数据按照Redis自己的协议将数据的写命令追加到临时aof文件，而是通过将当前内存中的数据以rdb的形式写入临时aof文件，然后将缓冲区的数据写命令以aof的形式追加到aof文件中。写入完成后通知主进程更新统计信息，并将新的含有rbd格式和aof格式的aof文件替换旧的的aof文件。简单的说：新的aof文件前半段是rdb格式的全量数据后半段是aof格式的增量数据。

开启混合模式后，在进行数据恢复时，Redis首先还是会优先从aof文件恢复数据，那么假设aof文件前半段有rdb格式的数据，那么会先加载rdb格式的数据，再执行aof的写命令。如果前半段没有rdb格式的数据，则直接安装aof文件恢复的模式继续恢复。

混合持久化结合了RDB持久化 和 AOF 持久化的优点, 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。

但是开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差。

[RDB]: /images/20221120/d9a6b227567d41e986bf20f6d4783d5e.png
[AOF]: /images/20221120/e8d863587c1848369faef579247e0611.png