Redis第11章 AOF持久化

• 前言：AOF和RDB不同，AOF会记录Redis执行的修改语句，并且不停的持久化到AOF文件中，恢复数据时回放一遍所有命令，所以理论上恢复速度会比RDB慢，虽然有重写功能，文章中也提到了，但是要启动子进程执行浪费资源，但AOF实时性比RDB好一些。

11.1 AOF持久化实现

• AOF持久化分为命令追加、文件写入、文件同步三个步骤

11.1.1 命令追加

struct redisServer{
//...
// AOF缓冲区
sds aof_buf;
//...
}

• 持久化功能打开时，服务器执行完命令会以特定协议格式把命令追加到apf_buf尾部。

11.1.2 AOF文件的写入与同步

• 文件写入：现代操作系统中，用户用程序调用write函数写文件时，系统默认会把数据保留在内存缓冲区，等到缓冲区填满或者超过指定时间才会真正写到磁盘上。这种做法好处是效率提升，坏处是宕机时缓冲区的数据就丢了。当然也可以手动配置每次都写到磁盘，或者程序触发，所以文件写入分为了写入和同步两个步骤。
• Redis服务器固定会有一个事件循环serverCron，这个后面章节会细说，serverCron默认每100ms执行一次，其中就有一个任务是把apf_buf持久化到AOF文件。
• serverCron不是每次都会同步到AOF文件，会有三种模式：
  • always：每次都把apf_buf内容写入并同步到AOF文件。安全性高，效率低
  • eversec：如果上次同步相隔超过一秒，就写入并同步。安全和效率的折中
  • no：只写入，什么时候同步操作系统决定。效率高，安全性低

11.2 AOF文件的载入与数据还原

• AOF文件包含了所有的执行语句，执行一遍就可以还原了
• 具体步骤：
  • 创建一个不联网的伪客户端（fake client）
  • 从AOF文件读取一条命令
  • 伪客户端执行命令

11.3 AOF重写

• 和RDB直接存数据不同，AOF一直追加执行命令的方式很容易导致文件过大，Redis提供了AOF重写（rewrite）功能。

11.3.1 AOF重写的实现

• rewrite：创建一个新的AOF文件，新文件替换旧文件，新AOF文件不会有任何冗余的命令。新AOF文件的实现是直接读取数据库放入AOF，这样就防止多次操作对象导致的命令冗余过多AOF文件过大。

11.3.2 AOF后台重写

• 防止服务进程阻塞，rewrite由子进程执行
• 子进程执行rewrite期间会有个问题，rewrite时服务进程也在处理请求，rewrite执行中某些数据可能持久化后又被服务进程修改了，导致数据不一致，所以加了一个AOF重写缓冲区，服务进程在rewrite期间除了正常处理数据、写入上面提到的AOF缓冲区，还把执行的命令记录到AOF重写缓冲区，子进程rewrite完成后再执行重写缓冲区的命令，这样rewrite结束时数据就被补全了，最后新AOF文件替换掉旧文件，rewrite流程结束。