【Redis持久化】AOF持久化机制
4.1 AOF持久化简介
AOF持久化机制： 对 每条写入的命令 作为日志，以 append-only的模式 写入到一个日志文件中。在Redis重启的时候，可以通过 回放AOF日志文件中的写入命令 重新构建整个数据集
4.2 AOF持久化的优点
-
AOF可以保证更少的数据不丢失，因为他备份的频率比较高，且不会影响Redis正常提供服务，通过每隔1秒，会通过一个后台线程执行一次fsync操作，最多丢失一秒的数据。
-
AOF日志文件 已 append-only 模式写入，所以没有磁盘寻址的开销，写入性能非常高，且文件不易损坏。
-
AOF日志文件过大时，出现后台重写操作，不会影响客户端的读写。因为rewrite log的时候，会对其中的数据进行压缩，创造一份需要回复数据的最小日志出来。再创建新的日志文件时，旧的日志文件照常写入。当新的merge后的日志文件准备好的时候，再交换老的日志文件。
-
AOF日志文件的命令通常通过非常可读的方式记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
4.3 AOF持久化的缺点
-
对同一份数据，AOF日志文件通常比RDB快照文件大的多，因此需要占用更多的存储空间。
-
AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也是非常高的，不会影响Redis正常为客户端提供服务。
-
AOF稳定性没有RDB强，通过AOF记录的日志文件，在进行数据恢复的时候，没有恢复出一模一样的数据出来。所以说，类似AOF这种复杂的基于命令/merge/回放的方式，比基于Rdb每次持久化重新拷贝一份完整的数据快照文件的方式，稳定性没有那么高，容易有bug。不过AOF就是为了避免 rewrite 过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行执行的重新构建，这样健壮性会好很多。
参考石衫老师 《亿级流量电商详情页系统》课程笔记
亲，如果觉得还不错，点个赞呗！！！你的鼓励是我坚持的最大源泉。