redis之AOF和RDB持久化

写在前面

因为redis数据是基于内存的，为了避免服务器重启或者是宕机导致数据全部丢失，提供了数据持久化机制，即AOF(Append Only File)日志和RDB快照，接下来我们分别看下。

1：AOF

1.1：AOF日志的实现

首先我们需要配置appendonly yes来打开AOF持久化，之后当我们执行完数据修改命令后，redis就会将命令记录到aof文件中，这个过程不同于MySQL的WAL机制，在写数据之前先写日志，redis是在写数据之后再写日志的，这样做的其中一个原因是可以不用对命令本身的语法进行校验了，该过程如下图：

如执行命令set aa bbbb则生成的aof日志如下：

*3
$3
set
$2
aa
$4
bbbb

含义如下：

*3：命令由3部分组成
$数字：代表接下来是命令的一部分，数字代表该部分的长度

通过以上信息就可以反推出命令set aa bbbb，就可以用来备份和恢复数据了。另外针对aof的写回策略提供了若干个参数来控制，接下来继续看下。

1.2：写回策略

目前redis的写回策略有三种，通过配置项appendfsync设置，如下：

Always：同步写回，使用主线程，所以会影响到主线程的性能。
Everysec：每秒写回，先将命令写到aof的缓冲区，然后其他线程每隔一秒写到aof文件。
No：操作系统控制写回，命令仅仅写道aof缓冲区，由操作系统控制写到aof文件。

对比如下表：

随着越来越多的命令写入到aof文件，aof文件会变得越来越大，而aof文件的不断增大可能会产生如下的问题:

1：达到了操作系统对单文件大小的限制，从而无法继续写入
2：文件增大之后数据写入的速度会变慢，影响写入性能
3：文件过大，数据恢复的速度慢

为了解决以上可能的问题，redis提供了AOF重写机制。

1.3：AOF重写机制

aof重写机制的原理是多合一，即将多个命令合并成一个命令，因为对通过一个key的操作可能会存在多次，所以对同一个key操作的命令会被记录多次，但是对于恢复数据而言，只需要最终的一个数据状态就行了，所以对于数据最终的状态，只需要对其反向生成一条命令即可，这就是多合一的过程，如下图对一个list的多次操作执行重写的过程：

为了完成AOF重写过程，redis会fork处一个新的子进程bgrewriteaof，并将当前内存中的数据拷贝一份，然后使用当前最新的数据生成对应的命令，并写到一个新的aof文件中，这个过程就是AOF重写，可以参考下图：

aof重写完成后，就可以使用新的aof文件替换旧的aof文件了。

写在后面

参考文章列表:

[]