Redis的AOF持久化机制

​ AOF持久化通过保存Redis服务器所执行的写命令来记录数据库状态。

AOF持久化的实现

​ 可以分为命令追加，文件写入，文件同步

1.命令追加

​ 当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾

struct redisServer{
    //....
    sds aof_buf;
    //...
}

2.AOF文件的写入与同步

​ Redis的服务器进程就是一个事件循环(loop).

​ 这个循环中的文件事件负责接收客户端的命令请求，以及向客户端发送命令回复，而时间事件则负责执行像serverCron函数这样需要定时运行的函数。

​

​ flushAppendOnlyFile函数的行为由服务器配置的appendfsync选项的值来决定

​

​ 为了提高文件的写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入到文件的时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里面，等到缓冲区的空间被填满、或者超过了指定的时限之后，才真正地将缓冲区中的数据写入到磁盘里面。

​ 会出现安全问题，如果计算机发生停机，那么保存在内存缓冲区里面的写入数据将会丢失。

​ 为此，系统提供了fsync和fdatasync两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里面，从而确保写入数据的安全性

​ AOF持久化的效率和安全性

​ 服务器配置appendfsync选项的值直接决定AOF持久化功能的效率和安全性。

• 当appendfsync的值为always时，服务器每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件中，并且同步AOF文件，所以always的效率是最慢的
• 当appendfsync的值为everysec时，服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件，并且每隔一秒就要在子线程中对AOF文件进行一次同步。最多也就损失1s的命令数据
• 当appendfsync的值为no时，服务器在每个事件循环都要将aof_buf缓冲区中的所有内容写入到AOF文件，至于何时对AOF文件进行同步，则由操作系统控制。

AOF文件的载入与数据还原

​ AOF文件里面包含了重建数据库状态所需的所有写命令，所以服务器只要读入并重新执行一遍AOF文件里面保存的写命令，就可以还原服务器关闭之前的数据库状态。

​ 详细步骤如下：

​

AOF重写

​ AOF中的内容会越来越多，文件的体积也会越来越大，如果不加以控制，体积过大的AOF文件很可能对Redis服务器，甚至整个宿主计算机造成影响。

AOF文件重写的实现

​ Redis将生成新AOF文件替换旧AOF文件的功能命名为“AOF文件重写”

​ 对于一些命令，例如

RPUSH list "A" "B"
RPUSH list "C"
LPOP list

​ 这可以简化为

RPUSH list "B" "C"

​ 也就是说AOF中的许多命令大多是可以进行简化的

​ 所以说，首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录这个键值对的多条命令，这就是AOF重写功能的实现原理。

​ 因为aof_rewrite函数生成的新AOF文件只包含还原当前数据库状态所必须的命令，所以新AOF文件不会浪费任何硬盘空间。

注意

​ 如果元素的数量超过了redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值，那么重写程序将使用多条命令来记录键的值，而不单单使用一条命令。

AOF后台重写

​ 因为Redis服务器使用单个线程来处理命令请求，所以如果由服务器直接调用aof_rewrite函数的话，那么在重写AOF文件期间，服务期将无法处理客户端发来的命令请求。

​ 而Redis不希望AOF重写造成服务器无法处理请求，则将AOF重写放到字==子进程==中执行，这样有两个好处：

• 子进程进行AOF重写期间，服务器进程（父进程）可以继续处理命令请求。
• 子进程带有服务器进程的数据副本，使用子进程而不是线程，可以在避免使用锁的情况下，保证数据的安全性。

另外，由于服务器进程和子进程是分别执行的，那么就有数据不一致的情况出现

​ 为了解决这种问题，Redis服务器设置了一个AOF重写缓冲区，这个缓冲区在服务器创建子进程之后开始使用，当Redis服务器执行完一个写命令之后，它会同时将这个写命令发送给AOF缓冲区和AOF重写缓冲区

​ 当子进程完成AOF重写工作之后，它会向父进程发送一个信号，父进程在接到该信号之后，会调用一个信号处理函数，并执行以下工作

• 将AOF重写缓冲区中的所有内容写入到新AOF文件中，这时新AOF文件所保存的数据库状态将和服务器当前的数据库状态一致。
• 对新的AOF文件进行改名，原子地（atomic）覆盖现有的AOF文件，完成新旧两个AOF文件的替换。

整个过程中，只有信号处理函数执行时会对服务器进程造成阻塞，其他AOF后台重写都不会阻塞父进程。这将AOF重写对服务器性能造成的影响降到最低。