简介

RDB持久化是全量备份，比较耗时，所以Redis就提供了一种更为高效地AOF(Append Only-file)持久化方案,AOF是一种写后日志，即先执行相关的命令，然后再将数据写入内存中。

AOF实现过程

图片.png

AOF重写机制

AOF为什么需要重写

随着Redis的运行，AOF的日志会越来越长，如果实例宕机重启，那么在重载整个AOF将会变得十分耗时，为了解决此问题，Redis提供了AOF重写，为了避免阻塞主线程，导致性能下降，Redis的AOF重写是由后台子进程 bgrewriteaof来完成的，主线程fork出后台的bgrewriteaof子进程，fork会把主线程的内存拷贝一份给bgrewriteaof子进程,并且包含最新的数据，然后bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

触发条件

在Reids中需要在redis.conf文件中进行相关配置，触发AOF的重写。

图片.png

no-appendfsync-on-rewrite：设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写，不开启AOF重写配置
auto-aof-rewrite-percentage:当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size:当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

回写策略

图片.png

appendonly:表示是否开启AOF，默认为No，Yes代表开启AOF
appendfilename: 设置AOF文件名称
appendfsync：AOF提供了三种fsync配置，always/everysec/no
always：每次发生数据修改就会立即记录到磁盘文件中，这种方案的完整性好但是IO开销很大，性能较差；
everysec：在每一秒中进行同步，速度有所提升。但是如果在一秒内宕机的话可能失去这一秒内的数据；
no：默认配置，即不使用 AOF 持久化方案。

针对避免主线程阻塞和减少数据丢失问题，这三种写回策略都无法做到两全其美，其每种方案的优缺点如下：

图片.png

AOF优缺点

优点

最安全，在启用appendfsync always时,任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据。
AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。
AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。

缺点

AOF文件通常比RDB文件更大，数据恢复速度比RDB慢
AOF性能消耗比RDB高

混合持久化

为了解决AOF和RDB持久化相关的缺点。Redis 4.0 提供了混合持久化方案，将 RDB 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF日志不再是全量的日志，而是自 RDB 持久化开始到持久化结束这段时间发生的增量AOF日志，从而减少了日志的大小。

图片.png

说明：在Redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志，这样就可以完全替代之前的AOF全量重放，从而提升重启效率。

总结

本文讲解了Redis的持久化之AOF机制，相比RDB而言，AOF的持久化机制更加的安全，但是也存在相应的缺点，实际的生产中我们需要结合Redis的这两种持久化方案，才能保证数据完整不丢失。