Redis的持久化机制-AOF实现原理详解

为什么要数据持久化？

Redis是内存数据库，如果不将数据存储到硬盘中，断电及失，存储在服务器中的数据也会消失，所以出现了持久化机制，两种持久化机制：RDB和AOF

AOF (Append Only File)

以日志的形式记录 Redis 的每一个写操作，将 Redis 执行过的所有写指令保存下来，以追加的形式保存到 AOF 文件 (默认为 appendonly.aof) 中当需要恢复数据时，Redis 会重新执行 AOF 文件中的写指令，来达到恢复数据的目的

AOF 相关配置

• appendonly
  
  当 appendonly 设置为 yes 时，表示开启 AOF 备份

• appendfilename
  
  appendfilename 用于指定 AOF 文件的名称，默认为 appendonly.aof

• appendfsync
  
  appendfsync 用于指定 AOF 文件的同步策略
  

AOF日志是如何实现的？

写后日志，先将数据写入内存，在写入日志

为什么要写后日志？

1）、redis记录日志的时候不会对命令的语法进行检查，如果先记录日志在执行命令的时候，日志中可能会记录了错误的日志，那么，在使用日志恢复数据时，会出错
2）、先执行再记录日志，不会阻塞当前的写操作

日志记录的内容都包括那些？

每一条命令，以文本形式保存
举例，执行指令set testkey testvalue

• *3：命令有3个部分
• $3后面紧跟具体的指令，指令的字长

AOF日志带来的风险

1、执行命令后还未记录日志就宕机，分为两种情况：
情况1，用作缓存：可从后端数据库恢复数据
情况2，直接作数据库：数据丢失
2、后续写入磁盘的操作无法进行
AOF虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险，因为，AOF操作是在主线程中执行的，把日志写进磁盘，磁盘压力大，导致速度慢，后续操作无法就进行

风险产生的原因？

分析AOF产生的风险，都和写入磁盘的时机相关，那么引出AOF的三种写入策略

三种写入策略

修改配置项：appendfsync

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

总结三种写入策略

AOF文件过大带来的性能问题

文件系统本身对文件大小的限制，超出则无法保存
文件过大，再追加，效率变低
宕机后，恢复过程很慢（执行所有的指令）

如何解决AOF文件不断增大的问题？

启用AOF重写机制

AOF重写机制介绍

Redis根据数据库的现状创建一个新的AOF文件，也就是说，在读取数据库的键值对时，对每个键值对用一条命令记录将它写入。比如，读取了键值对"k1":“v1"时，重写机制会记录 set k1 v1,这样，在恢复时，可以重新执行该命令，实现"k1”:"v1"的写入

触发 AOF 重写方式

客户端方式触发重写
执行BGREWRITEAOF命令

服务器配置方式自动触发
配置redis.conf中的auto-aof-rewrite-percentage选项
auto-aof-rewrite-percentage 100

aof 文件自上一次重写后文件大小增长了100%，则再次触发重写机制，比如说，上次AOF文件容量为100M，这次文件已经到200M了，则自动触发重写机制

auto-aof-rewrite-min-size 64mb

aof文件至少要达到64M才会触发自动重写，文件太小，恢复速度很快，重写意义不大

触发自动 AOF 重写条件

1. 没有 BGSAVE 命令在进行。
2. 没有 BGREWRITEAOF 在进行。
3. 当前 AOF 文件大小大于 server.aof_rewrite_min_size （默认值为 64 MB）。
4. 当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。

如果重写过于频繁，用户可以考虑将auto-aof-rewrite-percentage设置为更大

AOF重写机制的实现原理

首先调用 fork 指令，来创建一个子进程
然后子进程根据当前内存中的数据生成对应指令，并记录在一个临时 AOF 文件中，不需要依赖原有的 AOF 文件 (即不需要读取原有的 AOF 文件进行分析或指令合并)主进程会持续将新的变动同时写入到内存和原有的 AOF 文件中当子进程完成了临时 AOF 文件的创建后，会发送信号给主进程，此时主进程会往临时 AOF 文件中同步增量变动最后使用临时 AOF 文件替换原有的 RDB 文件我们可以通bgrewriteaof 指令来手动触发 AOF 文件的重写

为什么重写机制会把日志文件变小？

重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令我们知道，AOF 文件是以追加的方式，逐一记录接收到的写命令的。当一个键值对被多条写命令反复修改时，AOF 文件会记录相应的多条命令。但是，在重写的时候，是根据这个键值对当前的最新状态，为它生成对应的写入命令。这样一来，一个键值对在重写日志中只用一条命令就行了，而且，在日志恢复时，只用执行这条命令，就可以直接完成这个键值对的写入了
下面这张图就是一个例子：

当我们对一个列表先后做了 6 次修改操作后，列表的最后状态是[“D”, “C”, “N”]，
此时，只用 LPUSH u:list “N”, “C”, "D"这一条命令就能实现该数据的恢复，这就节省
了五条命令的空间。对于被修改过成百上千次的键值对来说，重写能节省的空间当然就更大了。不过，虽然 AOF 重写后，日志文件会缩小，但是，要把整个数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。这时，我们就要继续关注另一个问题了：重写会不会阻塞主线程？

AOF 重写会阻塞吗?

AOF重写日志，不会阻塞线程，AOF日志由主线程写回磁盘，AOF重写过程是由后台进程bgrewriteaof来完成的。主线程fork出后台的bgrewriteaof子进程，fork会把主线程的内存拷贝一份bgrewriteaof子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。所以aof在重写时，在fork进程时是会阻塞住主线程的。

操作系统中的父子进程关系

在父进程中通过fork()函数可以创建子进程，如果返回值==0，为子进程；否则是为父进程。子进程得到的除了代码段是与父进程共享以外，其他所有的都是父进程的一个副本，子进程的所有资源都继承父进程，得到父进程资源的副本，但是二者并不共享地址空间。两个是单独的进程，继承了以后二者就没有什么关联，子进程单独运行。采用写时复制技术。

总结

一个拷贝
“一个拷贝”就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此
时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的
最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数
据写成操作，记入重写日志

两处日志
因为主线程未阻塞，仍然可以处理新来的操作。此时，如果有写操作，第一处日志就是指
正在使用的 AOF 日志，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这
个 AOF 日志的操作仍然是齐全的，可以用于恢复。
而第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。这
样，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日
志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我
们就可以用新的 AOF 文件替代旧文件了。

AOF非阻塞重写过程

从持久化中恢复数据
其实想要从这些文件中恢复数据，只需要重新启动Redis即可。我们还是通过图来了解这个流程：

AOF修复工具的使用
如果append.aof文件有错误，是不能启动redis的，可以使用修复工具类修复这个aof文件redis-check-aof --fix

redis-check-aof --fix appendonly.aof

优势

具有更高的数据安全性，AOF 默认同步策略为每秒同步一次，因此即使 Redis 服务出现问题，那么最多也只会丢失最近一秒内修改的数据AOF 文件采用追加的形式进行保存，因此即使在写入过程中出现问题，也不会破坏日志文件中已经存在的内容；如果当我们的写入过程只进行了一半就出现了问题，那么在下一次 Redis 启动之前，我们可以通过 redis-check-aof 工具来帮助我们解决数据一致性的问题当日志文件过大时，我们可以通过重写机制来对 AOF 文件进行重写AOF 文件有序地保存了对数据库执行的所有写入操作，格式十分清晰，易于理解

劣势

对于相同的数据集而言，AOF 文件的体积通常要大于 RDB 文件的体积，且恢复速度慢根据同步策略的不同，AOF 的效率往往会低于 RDB，当我们采用同步禁用 (appendfsync no) 策略时，其效率和 RDB 相同