小健博客AOF 日志是先执行命令，把数据写入内存，然后才记录日志以文本形式保存，如下图：”*3″ 表示命令有三个部分组成，每部分由”$+数字”开头，”$3 set”表示这部分有三个字节，指”set”命令，”$7 testkey”表示该部分有七个字节，即”testkey”命令，以此类推。
AOF 写后日志只有命令能执行成功，才会被记录到日志中，避免额外的检查开销，也避免了出现记录错误命令的情况，而且不会阻塞当前的写操作。说完 优点 说 风险 ，如果刚执行完命令还没有来得及记日志就宕机了，就有丢失的风险。其次，AOF 日志在主线程中执行，如果在把日志文件写入磁盘压力过大，可能会带来阻塞风险。
AOF 风险与写回磁盘有关，针对这个问题提供了三种 写回策略 ，即配置项 appendfsync 的三个可选值：
（1）Always 同步写回：每个写命令执行完，立马同步地将日志写回磁盘
（2）Everysec 每秒写回：每个写命令执行完，先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘
（3）No 操作系统控制的写回：每个写命令执行完，先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
三种策略各有优劣，汇总如下：
选定写回策略，并非万事大吉，随着接收的写命令越来越多，AOF 文件会越来越大，带来性能问题。主要是以下三个方面：
（1）文件系统本身对文件大小有限制，无法保存过大的文件
（2）如果文件太大，之后再往里面追加命令记录的话，效率也会变低
（3）如果发生宕机，AOF 中记录的命令要一个个被重新执行，文件太大导致整个恢复过程就会非常缓慢，影响 Redis 正常使用
日志文件太大了怎么办呢？这个时候，AOF 重写机制 就登场了。当一个键值对被多条写命令反复修改时，AOF 文件会记录相应的多条命令，而重写时，只会根据这个键值对当前的最新状态，为它生成对应的写入命令，这样一来，一个键值对在重写日志中只用一条命令就行了，并且在日志恢复时，只用执行这条命令，就可以直接完成这个键值对的写入了。举个栗子：
AOF 重写并不会阻塞主线程，重写过程是由后台线程 bgrewriteaof 来完成的，通过内存拷贝和两处日志保证数据的完整性。
