Redis 持久化RDB和AOF原理

比眉伴天荒 2022-06-08 14:42 169阅读 0赞

**Redis持久化是如何工作的?**

持久化就是把数据放到断电后数据不会丢失的设备中，也就是我们通常理解的磁盘上。数据库在进行写操作时，有以下五个过程:

*  1) 客户端往服务器发送写操作(数据在客户端的内存中)
 *  2) 数据库服务端接受到写请求的数据(数据在服务端的内存中)
 *  3) 服务端调用write这个系统调用,把数据往磁盘写(数据在系统内存的缓存区中)
 *  4) 操作系统把缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)
 *  5) 磁盘控制器把数据写到磁盘的物理介质中(数据真正存储到磁盘中)

**故障分析**

结合上面的5个流程查看各种级别的故障:

*  当数据库系统故障时，这时候系统内核还是完好的。那么此时只要我们执行完了第3步，那么数据就是安全的，因为后续操作系统会来完成后面几步，保证数据最终会落到磁盘上。
 *  当系统断电时，这时候上面5项中提到的所有缓存都会失效，并且数据库和操作系统都会停止工作。所以只有当数据在完成第5步后，才能保证在断电后数据不丢失。

因此需要考虑的问题是：

*  数据库多长时间调用一次write,把数据写到内核缓冲区？  
    
    
     *  通常数据库层面会进行全面控制
 *  内核多长时间会把系统缓冲区上的数据写到磁盘控制器?  
    
    
     *  操作系统有默认的策略，也可以通过POSIX API提供的fsync系统命令强制操作系统把数据从内核写到磁盘控制器
 *  磁盘控制器又在什么时候把缓存中的数据写到磁盘介质?  
    
    
     *  建议的做法是仅仅当磁盘设备有备用电池时才开启写缓存

数据损坏

数据损坏就是数据无法回复，写道磁盘上并不意味着数据不会损坏，比如我们可能一次写请求会进行两次不同的写操作，当意外发生时，可能会导致一次写操作完成，但是另外一次还没有执行。如果数据库的数据文件结构组织不合理，就会导致数据不能完全恢复。

有三种策略来组织数据来防止数据损坏到无法恢复的情况

*  不通过数据的组织形式保证数据的可恢复性，而是通过配置数据同步备份的方式，在数据文件损坏后通过数据备份来进行恢复。实际上MongoDB在不开启操作日志，通过配置Replica Sets时就是这种情况。
 *  在上面的基础上添加一个操作日志，每次操作时记一下操作的行为，这样可以通过操作日志来进行数据恢复。因为操作日志是顺序追加的方式写的，所以不会出现操作日志也无法恢复的情况
 *  数据库不进行旧数据的修改，只用追加的方式完成写操作，这样数据本身就是一份日志，这样就永远不会出现数据无法恢复的情况了。实际上CouchDB就是此做法的优秀范例。

**RDB快照**

Redis支持把当前数据的快照存成一个数据文件的持久化机制。而一个持续写入的数据库如何生成快照呢。Redis借助了fork命令的copy on write机制。在生成快照时，将当前进程fork出一个子进程，然后在子进程中循环所有的数据，将数据写成为RDB文件。

我们可以通过Redis的save指令来配置RDB快照生成的时机，比如你可以配置当10分钟以内有100次写入就生成快照，也可以配置当1小时内有1000次写入就生成快照，也可以多个规则一起实施。这些规则的定义就在Redis的配置文件中

![这里写图片描述][SouthEast]

下面可以看到备份文件的文件名和存放目录

![这里写图片描述][SouthEast 1]

![这里写图片描述][SouthEast 2]

也可以通过Redis的CONFIG SET命令在Redis运行时设置规则，不需要重启Redis

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的，当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件，这样在任何时候出现故障，Redis的RDB文件都总是可用的。

同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。

但是，我们可以很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从**上次RDB文件生成到 Redis停机这段时间的数据全部丢掉了**。在某些业务下，这是可以忍受的，而且开启RDB的代价并不高。 但是对于另外一些对数据安全性要求极高的应用，无法容忍数据丢失的应用，RDB就无能为力了，所以Redis引入了另一个重要的持久化机制：AOF日志

**AOF日志**

AOF日志的全称是Append Only File，从名字上我们就能看出来，它是一个追加写入的日志文件。与一般数据库不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。比如我们进行如下实验，在启动命令参数中设置开启AOF功能：

这里演示的是使用命令行参数开启AOF日志的方式，后面会记录如何使用配置文件开启AOF日志

[root@VM_75_51_centos redis]# ./bin/redis-server ./redis.conf --appendonly yes
    13336:C 28 Sep 15:00:30.750 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    13336:C 28 Sep 15:00:30.750 # Redis version=4.0.2, bits=64, commit=00000000, modified=0, pid=13336, just started
    13336:C 28 Sep 15:00:30.750 # Configuration loaded
    [root@VM_75_51_centos redis]# ls 
    appendonly.aof  bin  dump.rdb  redis.conf

我们在数据库添加一些key再全部删除

[root@VM_75_51_centos redis]# ./bin/redis-cli 
    127.0.0.1:6379> set key1 hello
    OK
    127.0.0.1:6379> set key2 world
    OK
    127.0.0.1:6379> set key3 redis
    OK
    127.0.0.1:6379> keys *
    1) "key1"
    2) "key3"
    3) "key2"
    127.0.0.1:6379> flushall
    OK
    127.0.0.1:6379> keys *
    (empty list or set)

此时关闭redis服务器，打开AOF日志文件appendonly.aof

127.0.0.1:6379> shutdown
    not connected> exit
    [root@VM_75_51_centos redis]# ls 
    appendonly.aof  bin  dump.rdb  redis.conf
    [root@VM_75_51_centos redis]# vi appendonly.aof 
    *2
    $6
    SELECT
    $1
    0
    *3
    $3
    set
    $4
    key1
    $5
    hello
    *3
    $3
    set
    $4
    key2
    $5
    world
    *3
    $3
    set
    $4
    key3
    $5
    redis
    *1
    $8
    flushall

可以看到日志是明文存储的，我们把最后一行flushall删除再重新启动服务器

[root@VM_75_51_centos redis]# ./bin/redis-server ./redis.conf --appendonly yes
    13686:C 28 Sep 15:04:54.120 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    13686:C 28 Sep 15:04:54.120 # Redis version=4.0.2, bits=64, commit=00000000, modified=0, pid=13686, just started
    13686:C 28 Sep 15:04:54.120 # Configuration loaded
    [root@VM_75_51_centos redis]# ./bin/redis-cli 
    127.0.0.1:6379> keys *
    1) "key2"
    2) "key1"
    3) "key3"
    127.0.0.1:6379>

可以看到数据恢复了

此外注意AOF日志也不是完全按客户端的请求来生成日志的，比如命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录，因为浮点数操作可能在不同的系统上会不同，所以为了避免同一份日志在不同的系统上生成不同的数据集，所以这里只将操作后的结果通过SET来记录。

前面是使用命令行参数开启AOF日志，也可以在redis.conf中配置

找到appendonly no改成appendonly yes

![这里写图片描述][SouthEast 3]

再选择合适的持久化策略

![这里写图片描述][SouthEast 4]

*  appendfsync always 每次修改都会进行持久化
 *  appendfsync everysec 每秒进行持久化
 *  appendfsync no 不主动进行持久化 依赖操作系统

这里选择第一个 修改完毕再启动服务器就可以了

**AOF重写**

每一条写命令都生成一条日志，那么AOF文件是不是会很大？答案是肯定的，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件。

**持久化性能是否可靠**

从上面的流程中可以看出，RDB是顺序IO，性能很高。而同时在通过RDB文件进行数据恢复的时候也是顺序的读取数据加载到内存中，所以不会造成磁盘的随机读取错误

而AOF是一个写文件操作，其目的是将操作日志写到磁盘上，所以它也同样会遇到上面说的写操作的5个流程。那么写AOF的操作安全性又有多高呢？实际上这是可以设置的，在Redis中对AOF调用write写入后，何时再调用fsync将其写到磁盘上，通过appendfsync选项来控制，下面appendfsync的三个设置项，安全强度逐渐变强。

1、appendfsync no

当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。

2、appendfsync everysec

当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一 次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。

所以，结论就是：在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。

这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。

3、appednfsync always

当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。

对于pipelining有什么不同？

对于pipelining的操作，其具体过程是客户端一次性发送N个命令，然后等待这N个命令的返回结果被一起返回。通过采用pipilining 就意味着放弃了对每一个命令的返回值确认。由于在这种情况下，N个命令是在同一个执行过程中执行的。所以当设置appendfsync为everysec 时，可能会有一些偏差，因为这N个命令可能执行时间超过1秒甚至2秒。但是可以保证的是，最长时间不会超过这N个命令的执行时间和。

和其他数据库的比较

1.在数据导入方面的比较

持久化的数据用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以 Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。相对于MySQL等数据库的启动时间来说，会长很多，因为MySQL本来是不需要将数据加载到内存中的。

但是相对来说，MySQL启动后提供服务时，其被访问的热数据也会慢慢加载到内存中，通常我们称之为预热，而在预热完成前，其性能都不会太高。而Redis的好处是一次性将数据加载到内存中，一次性预热。这样只要Redis启动完成，那么其提供服务的速度都是非常快的。

而在利用RDB和利用AOF启动上，其启动时间有一些差别。**RDB的启动时间会更短**，原因有两个

*  一是RDB文件中每一条数据只有一条记录，不会像 AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。
 *  另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作。在CPU消耗上要远小于AOF日志的加载。

--------------------

参考文章

[http://oldblog.antirez.com/post/redis-persistence-demystified.html][http_oldblog.antirez.com_post_redis-persistence-demystified.html]

[SouthEast]: /images/20220608/5f4e4ff250e44f1db6bc1618620b28f3.png
[SouthEast 1]: /images/20220608/c821cdf386554be1be5b61f79c7e9301.png
[SouthEast 2]: /images/20220608/ea223f102f18494d910d48238a1b7cf2.png
[SouthEast 3]: /images/20220608/ba2ba40762be4849adc68283b596a5a4.png
[SouthEast 4]: /images/20220608/6572c6fd54a042efa9440fb10d10fc07.png
[http_oldblog.antirez.com_post_redis-persistence-demystified.html]: http://oldblog.antirez.com/post/redis-persistence-demystified.html