Redis持久化之AOF

AOF是Redis的另一种持久化方式。

什么是AOF？

AOF是指Redis会将每一个接收到的写命令通过write函数追加到文件（默认为appendonly.aof）中，因此，AOF有着比RDB更好的持久化性。当然AOF方式的持久化也有可能丢失部分修改。

AOF的实现原理

客户端发送写命令到服务端，服务端接收并执行一个写命令后，会以协议格式将被执行的写命令追加到aof_buf缓存区末尾，在服务端结束一个事件循环之前，会调用flushAppendOnlyFile函数，检查是否需要将aof_buf缓存区内的内容写入和保存到AOF文件中，是否写入由Redis的配置appendfsync的值来决定的。在Redis重启时，会通过执行文件中的写命令完成在内存中重建整个数据库内容的任务。AOF文件中保存的是被执行的写命令。

AOF相关配置（【Redis的配置文件】配置文件的第934行）

appendonly，是否开启aof方式

127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly yes
OK
127.0.0.1:6379> config get appendonly 
1) "appendonly"
2) "yes"

 appendfilename，aof文件名，默认为appendonly.aof

appendfsync，写入与同步的方式

127.0.0.1:6379> config get appendfsync
1) "appendfsync"
2) "everysec"

appendfsync选项值和含义

everysec：将aof_buf缓存区的所有内容写入到aof文件，如果上次同步aof文件的时间与当前时间大于1秒，那么会再次对aof文件进行同步，同步操作由一个线程专门负责；不间断的写入，隔一秒同步一次，效率较快，安全性较高（异常时，最多丢失一秒数据）。

always：将aof_buf缓存区的所有内容写入并同步到aof文件；不间断的写入和同步，效率最慢，安全性最高。

no：将aof_buf缓存区的所有内容写入到aof文件，但不会进行同步操作，同步操作的时间由操作系统决定；不间断写入，效率最高，但是安全性最低（异常时，会丢失未同步数据）。

no-appendfsync-on-rewrite，正在导出rdb快照时，是否停止同步aof

127.0.0.1:6379> config get no-appendfsync-on-rewrite
1) "no-appendfsync-on-rewrite"
2) "no"

auto-aof-rewrite-percentage ，当前的aof文件的大小超过上一次文件大小的百分比时，会触发重写。
auto-aof-rewrite-min-size ，限制了允许重写的最小文件大小，当aof文件达到这个值时，触发重写。

127.0.0.1:6379> config get auto-aof-rewrite-percentage
1) "auto-aof-rewrite-percentage"
2) "100"
127.0.0.1:6379> config get auto-aof-rewrite-min-size
1) "auto-aof-rewrite-min-size"
2) "67108864"

AOF持久化会保存每一条被执行的写命令，那么随着服务器运行时间的增长，对应的aof文件内容会越来越多，文件也会越来越大，从而对服务器造成影响，为此，Redis提供了文件重写的功能，来解决aof文件过大问题，它是通过重写程序aof_write实现的。具体是怎么回事呢？举个例子：

127.0.0.1:6379> rpush listA a
(integer) 1
127.0.0.1:6379> rpush listA b c 
(integer) 3
127.0.0.1:6379> lpop listA
"a"
127.0.0.1:6379> lpush listA m n
(integer) 4
127.0.0.1:6379> lrange listA 0 -1
1) "n"
2) "m"
3) "b"
4) "c"
127.0.0.1:6379> exit
[root@localhost src]# cat appendonly.aof 

 

RESP协议：就上面截图中某条完整的命令为例，*4：你可以将*理解为开始标识，4表示该命令（rpush listA b c）总共四部分组成；$5：表示命令第一部分的长度，eg：rpush的长度为5。

经过了上面的4条新增/移除命令后，得到的结果是4个元素。

手动重写下：

[root@localhost src]# ./redis-cli
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

跟rpush listA n m b c命令是类似的，也就是说重写不是依次读取aof文件的命令，而是直接去记录了当前数据库数据的最终值，这样，服务器就能以最少的命令记录数据库所有数据的状态。

aof文件重写时，Redis为了避免重写操作时，服务器线程被长时间阻塞的情况发生，将重写程序放到子线程中执行，以保证服务器能继续处理客户端发来的命令请求，这样就可能出现数据库状态不一致。为解决这一问题，Redis服务器设置了aof重写缓冲区，这个缓存区在创建子线程进行重写操作时会开始工作。子进程完成aof缓冲区的重后，会向父进程（服务器进程)确定是否需要向文件中继续追加命令，如果存在新命令需要追加，则子进程会在追加完命令后再次向父进程确定，直到不需要再追加命令，最后，这个新aof文件将会替换掉旧aof文件。

 

 

如果有写的不对的地方，请大家多多批评指正，非常感谢！