2.2、AOF
AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像 Mysql 中的binlog。AOF更适合做热备。
优点：
AOF是一秒一次去通过一个后台的线程fsync操作，数据丢失不用怕。
缺点：
1、对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2、根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的。
AOF整个流程分两步：第一步是命令的实时写入，不同级别可能有1秒数据损失。命令先追加到aof_buf然后再同步到AO磁盘，如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。
第二步是对aof文件的重写，目的是为了减少AOF文件的大小，可以自动触发或者手动触发(BGREWRITEAOF)，是Fork出子进程操作，期间Redis服务仍可用。
1、在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；它依然会写入旧的AOF中，如果重写失败，能够保证数据不丢失。
2、为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。
3、重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
4、无论是 RDB 还是 AOF 都是先写入一个临时文件，然后通过rename完成文件的替换工作。
关于Fork的建议：
1、降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写；
2、控制Redis最大使用内存，防止fork耗时过长；
3、配置牛逼点，合理配置Linux的内存分配策略，避免因为物理内存不足导致fork失败。
4、Redis在执行BGSAVE和BGREWRITEAOF命令时，哈希表的负载因子>=5，而未执行这两个命令时>=1。目的是尽量减少写操作，避免不必要的内存写入操作。
5、哈希表的扩展因子：哈希表已保存节点数量 / 哈希表大小。因子决定了是否扩展哈希表。
2.3、恢复
启动时会先检查AOF(数据更完整)文件是否存在，如果不存在就尝试加载RDB。
