Redis持久化之AOF日志

AOF (Append Only Fil)日志是写后日志，Redis 是先执行命令，把数据写入内存，然后才记录日志。

1. 为了避免额外的检查开销，Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令
2. 在命令执行后才记录日志，所以不会阻塞当前的写操作。

 

AOF 机制给我们提供了三个选择，也就是 AOF 配置项appendfsync 的三个可选值。

1. Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

2. Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；

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

随着命令越写越多，AOF的文件会变大，这里就会带来性能的影响：

1. 文件系统本身对文件大小有限制，无法保存过大的文件；
2. 如果文件太大，之后再往里面追加命令记录的话，效率也会变低；
3. 如果发生宕机，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用。

 

AOF 重写机制

AOF 重写机制就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文件，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。注意这里是一个键值对只对应一条命令，那么一些旧数据就不用写入了，AOF重写之后，日志文件会变小。

为了不影响主线程，redis的重写是由后台线程bgrewriteaof来完成的，主要的特征如下：

1. 主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，包含了数据库的最新数据。子进程是会拷贝父进程的页表，即虚实映射关系，而不会拷贝物理内存。子进程复制了父进程页表，也能共享访问父进程的内存数据了，此时，类似于有了父进程的所有内存数据。
2. 主线程可以继续处理请求，如果有写操作，会把这个操作写到正在使用的AOF日志的缓冲区。
3. 同时新的写操作也会被写到重写日志的缓冲区，等拷贝完后，这些新的操作也会写入新的AOF文件中。