redis持久化之AOF（Append Only File）

1 : AOF 是什么

以日志的形式来记录每个写操作（增量保存），将redis执行过的所有写指令记录下来（读操作不记 录），只允追加文件但不可改写文件，redis启动之初会读取该文件重新构造数据，换言之，redis重启
的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2 : AOF持久化流程

1. 客户端的请求写命令会被append追加到AOF缓冲区内
2. AOF缓冲区会根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写（rewrite），压缩AOF文件容量
4. redis服务器重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

3 : AOF默认不开启

可以在 redis.conf 文件中对AOF进行配置

1. appendonly no # 是否开启AOF，yes：开启，no：不开启，默认为no
2. appendfilename “appendonly.aof” # aof文件名称，默认为appendonly.aof
3. dir ./ # aof文件所在目录，默认./，表示执行启动命令时所在的目录，比如我们在/opt目录中，去执行
4. redis-server /etc/redis.conf 来启动redis，那么dir此时就是/opt目录

4 : 、AOF和RDB同时开启，redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

5 : AOF启动/修复/恢复

AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件， 需要恢复时再拷贝到Redis工作目录下，启动系统即加载

正常恢复

1. 修改默认的appendonly no，改为yes
2. 将有数据的aof文件复制一份保存到对应的目录（查看目录：config get dir）
3. 恢复：重启redis然后重新加载

异常恢复

1. 修改默认的appendonly no，改为yes
2. 如遇到aof文件损坏，通过 /usr/local/bin/redis-check-aof --fix appendonly.aof 进行
恢复

6 : AOF同步频率设置

可以在redis.config中配置AOF同步的频率

appendfsync always：每次写入立即同步

始终同步，每次redis的写入都会立刻记入日志；性能较差但数据完整性比较好。

appendfsync everysec：每秒同步

每秒同步，每秒记录日志一次，如果宕机，本秒数据可能丢失；更新的命令会放在内存中AOF缓冲区，每秒将缓冲区的命令追加到AOF文件

appendfsync no：不主动同步

redis不主动进行同步，把同步交给操作系统。

7 : rewrite压缩（AOF文件压缩）

7.1rewrite压缩是什么？

AOF采用文件追加方式，文件会越来越大，为了避免出现此情况，新增了重写机制，当AOF文件的大小
超过锁审定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使 用命令bgrewriteaof触发重写。

7.2重写原理，如何实现重写？

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件，最后在rename替
换旧文件），redis4.0版本后的重写，是指就把rdb的快照，以二进制的形式附在新的aof头部，作为已
有的历史数据，替换掉原来的流水账操作。

7.3触发机制，何时重写？

bgrewriteaof：手动触发重写

从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， bgrewriteaof 仅仅用于手动触发重写操作。
redis会记录上次重写的aof大小，默认配置是当aof文件大小是上次rewrite后大小的2倍且文件大于64M 时触发。
重写虽然可以节约大量磁盘空间，减少恢复时间，但是每次重写还是有一定负担的，因此设置redis满足 一定条件才会进行重新。

7.4 auto-aof-rewrite-percentage：设置重写基准值

设置重写的基准值，默认100，当文件达到100%时开始重写（文件是原来重写后文件的2倍时重写）。

7.5 auto-aof-rewrite-min-size：设置重写基准值

设置重写的基准值，默认64MB，AOF文件大小超过这个值开始重写。

举个例子

文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB
系统载入时或者上次重写完毕时，redis会记录此时AOF大小，设置base_size。
如果Redis的AOF当前大小>=base_size+base_size*100%( auto-aof-rewrite-percentage
默认值) 且 当 前大小>=64mb( auto-aof-rewrite-min-size 默认值)的情况下，redis会对AOF进行重写

8 重写流程

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

1. 手动执行 bgrewriteaof 命令触发重写，判断是否当前有bgfsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行
2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞
3. 子进程遍历redis内存中的数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和
   aof_rewrite_buf重写缓冲区保证原AOF文件完整性以及新AOF文件生成期间的新的数据修改动作不会丢失
4. 子进程写完新的AOF文件后，向主进程发送信号，父进程更新统计信息
5. 主进程把aof_rewrite_buf中的数据写入到新的AOF文件
6. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写

no-appendfsync-on-rewrite：重写时，不会执行appendfsync操作

该参数表示在正在进行AOF重写时不会将AOF缓冲区中的数据同步到旧的AOF文件磁盘，也就是说在进
行AOF重写的时候，如果此时有写操作进俩，此时写操作的命令会放在aof_buf缓存中（内存中），而不
会将其追加到旧的AOF文件中，这么做是为了避免同时写旧的AOF文件和新的AOF文件对磁盘产生的压 力。

默认是ON，表示关闭，即在AOF重写时，会对AOF缓冲区中的数据做同步磁盘操作，这在很大程度上保 证了数据的安全性。

但在数据量很大的场景，因为两者都会消耗磁盘IO，对磁盘的影响较大，可以将其设置为“yes”减轻磁盘
压力，但在极端情况下可能丢失整个AOF重写期间的数据。

如果no-appendfsync-on-rewrite为yes，不写入aof文件，只写入缓存，用户请求不会阻塞，但是在这
段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

如果no-appendfsync-on-rewrite为no，还是会把数据库往磁盘里刷，但是遇到重写操作，可能会发生
阻塞。（数据安全，但是性能降低）

9 : AOF优势

1. 备份机制更稳健，丢失数据概率更低
2. 可读的日志文本，通过操作AOF文件，可以处理误操作

10 : 劣势

1. 比RDB占用更多的磁盘空间
2. 恢复备份速度要慢
3. 每次读写都同步的话，有一定的性能压力
4. 存在个别bug，造成不能恢复

小总结 :

1. AOF文件是一个只进行追加的日志文件
2. edis可以在AOF文件体积变得过大时，自动地在后台对AOF文件进行重写
3. AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此
AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松。
4. 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
5. 根据所使用的fsync策略，AOF的速度可能会慢于RDB

总结 : 用哪个好？

1. 官方推荐2个都启用。
2. 如果对数据不敏感，可以单独用RDB。
3. 不建议单独使用AOF，因为可能会出现BUG。
4. 如果只是做纯内存缓存，可以都不用。

官方建议 :