Redis居然还有比RDB和AOF更强大的持久化方式？

Redis居然还有比RDB和AOF更强大的持久化方式？

介绍

Redis中的数据存在内存中，如果突然宕机，那么内存中的数据将全部丢失。如果数据能从后端数据库恢复还好，如果数据只存在Redis中，那数据就全丢失了。并且如果请求量很多，MySQL服务器的压力会很大。

所以最好的方式是对数据进行持久化，并能当宕机的时候能快速恢复

「在Redis中有如下两种持久化方式，rdb快照和aof日志」

RDB

rdb就是对当前数据库的状态做一个快照，将某个阶段的数据通过二进制文件保存下来。你可以类比照相。内存中的数据越多，生成快照的时候就越长，同时将快照写入磁盘耗费的时间也越长。

「这时我们不经要问，生成快照会阻塞主线程吗?」 如果会阻塞主线程，则会影响正常请求的处理

在Redis中有两个命令可以用于生成RDB文件，一个是save，另一个是bgsave

save：在主线程中执行，会导致阻塞bgsave：主线程fork出一个子进程负责创建rdb文件，不会阻塞主线程

我们当然毫不犹豫的选择bgsave，毕竟不会阻塞主线程

「那当我们使用bgsave时生成镜像的时候数据还能被修改吗?」

如果数据允许被修改，会有很多问题。例如，bgsave子进程刚持久化完一个key，结果主线程就把这个key给删了，会造成数据不一致。

如果数据不允许被修改，那么所有写操作只能等到rdb文件生成完才能执行，影响性能。

「这时我们就不得不提到COW了，redis是使用多进程COW机制来实现快照持久化的」

Copy-On-Write，COW

Redis在进行持久化的时候，会fork出一个子进程，快照持久化交给子进程来完成。子进程刚刚产生的时候，它和父进程共享里面的数据段和代码段。所以在进程分离的一瞬间，内存的增长机会没有变化。

子进程做持久化，不会修改内存中的数据，但是主线程不一样，它会持久接收客户端的修改请求，然后修改内存中的数据。

这时就会使用操作系统的COW机制来进行数据段页面的分离。数据段由很多操作系统的页面组成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时的数据。

随着父进程修改操作的进行，越来越多共享的页面被分离出来，页面就会持续增长，但是不超过原有内存的2倍。

「子进程中的数据一直没有变化，它就可以安心的做持久化了。」

如果每隔1分钟生成一个快照，宕机后还是会丢失快照生成后所执行的操作(最多为1分钟之内的操作)。我们把生成快照的时间缩短，又会影响Redis性能，毕竟fork子进程会阻塞主线程，频繁读写磁盘，也会给磁盘带来很大压力。

这是就不得不提到另一种持久化的方式，aof日志

AOF

当我们每次执行一条命令的时候，把对应的操作记到aof日志中，当redis宕机的时候我们只要重放日志就能恢复数据。而且Redis是以文本的形式保存aof日志的

例如当我们执行如下一条命令

set key value

aof文件中就会追加如下的内容

*3 $3 set $3 key $5 value

*3表示当前命令有3个部分，每部分都是由“$+数字开头”，数字表示命令，键或者值由几个字节组成

需要注意的是，「redis中记录的是写后日志」，即先执行命令，再写日志。那要是命令执行成功，还没有来得及写日志?那么服务宕机后这条命令不是丢失了?因为aof日志是在主线程中写入的，如果每次写日志都刷到磁盘，岂不是很影响性能?

好在redis给我们提供了三种写aof日志的方式

「always」：同步写回，写命令执行完就同步到磁盘

「everysec」：每秒写回，每个写命令执行完，只是先把日志写到aof文件的内存缓冲区，每隔1秒将缓冲区的内容写入磁盘

「no」：操作系统控制写回，每个写命令执行完，只是先把日志写到aof文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回到磁盘

当aof的刷盘机制为always，redis每处理一次写命令，都会把写命令刷到磁盘中才返回，整个过程是在Redis主线程中进行的，势必会拖慢redis的性能

当aof的刷盘机制为everysec，redis写完内存后就返回，刷盘操作是放到后台线程中去执行的，后台线程每隔1秒把内存中的数据刷到磁盘中

当aof的刷盘机制为no，宕机后可能会造成部分数据丢失，一般不采用。

「一般情况下，aof刷盘机制配置为everysec即可」

aof日志是通过保存被执行的写命令来记录数据库状态的，随着时间的流逝，aof日志会越来越大，使用aof文件来还原数据所需要的时间也越来越长。有没有什么优化方案呢?此时aof日志重写登场了。

AOF日志重写

假如说客户端依次执行了如下5条命令

127.0.0.1:6379> rpush list 1 (integer) 1  // [1] 127.0.0.1:6379> rpush list 2 (integer) 2  // [1, 2]  127.0.0.1:6379> rpush list 3 (integer) 3  // [1, 2, 3] 127.0.0.1:6379> lpop list "1" // [2, 3] 127.0.0.1:6379> rpush list 1 (integer) 3 // [2, 3, 1]

单独记list这个key的状态就得有5条日志。要是能把这5条命令合并成 rpush list 2 3 1这个命令就好了。其实这就是aof日志重写要干的事情，那么如何实现呢?

虽然Redis将生成新的aof文件的功能命名为"aof重写"，但是aof重写并不需要对现有aof文件进行任何读取，分析操作。而是直接读取读取内存中的最新值，然后保存对应的命令。

例如上面的例子，redis直接读取list的值，并生成一条rpush list 2 3 1命令放到aof日志中。

「可以看到aof重写是一个非常耗时的操作，那么它会阻塞主线程吗?」

不会，因为作为一种优化手段，Redis肯定不希望它被阻塞。所以每次重写的时候主线程fork出一个bgrewriteaof子进程。bgrewriteaof子进程使用Copy-On-Write技术来读取内存中的数据，写新的aof日志

「那在重写aof日志的过程中，主线程执行的操作该怎么写到新的aof日志中?」

其实在aof日志重写的过程中，主线程会把操作同步到aof缓冲区和aof重写缓冲区。当子线程完成aof重写，并且将aof重写缓冲区的内容，写入新的aof日志中时，就会用新的aof日志代替旧的aof日志

「Redis生成rdb文件和aof日志重写，都是通过主线程fork子进程的方式，让子进程来执行的」

Redis4.0混合持久化「当使用RDB做持久化时，宕机后会造成一部分数据的丢失」，此时可以缩短生成RDB快照的时间间隔，但是如果频繁的生成RDB快照，有会有如下两方面的问题

频繁的将全量数据写到磁盘，会给磁盘造成很大的压力

主线程fork子进程来生成rdb快照，子进程生成rdb快照不会阻塞主线程，但是主线程通过fork创建子进程的过程会阻塞主线程，主线程的内存越大，阻塞时间越长。

「当使用AOF做持久化的时候，数据完整性较高，但是宕机后恢复时间比较长。」

那有没有什么方法?即能做到快速恢复，又能保证数据完整性较高?

你别说，还真有。Redis4.0提出了一种混合持久化的方式。就是快照按照一定的频率执行，在2次快照之间，用aof日志记录这个期间所有的命令操作。当第2次快照生成的时候可以清空aof文件，因为此时命令已经记录到快照中了。

在Redis重启的时候，可以先加载rdb文件的内容，然后重放aof日志即可。

区别

rdbaof

持久化方式 生成某一时刻快照文件 实时记录写命令到日志 数据完整性 不完整，取决于备份周期 完整性相对较高，取决于刷盘机制 文件大小 二进制文件，相对较小 保存原始命令，文件较大 宕机恢复时间 快 慢 使用场景 宕机需要快速恢复，允许一定数量的数据丢失 对数据可靠性要求较高

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。