AOF日志是如何实现的
对于传统数据库的日志，一般采取的是写前日志（Write Ahead Log，WAL），顾名思义，就是在实际写数据前先把修改的数据记到日志文件中，以便故障时进行恢复。而 AOF 日志正好相反，它是写后日志，即 Redis 先执行命令，把数据写入内存，然后才将日志记录写入磁盘。其实很容易辨别，传统数据库更多想要的是回退故障前的数据，而 redis 更多想要的是找回故障丢失的数据。
传统数据库的日志，例如 redo log（重做日志），记录的是修改后的数据，而 AOF 里记录的是 Redis 收到的每一条命令（ 操作 + 键名 + 键值，以及这三部分对应的字节长度 ），这些命令是以文本形式保存的。
以set name kwingtaai为例，AOF 日志中将会记录 *3 $3 set $4 name $9 kwingtaai 其中 *3 表示该命令有三个组成部分，$3 set 表示这个命令的操作为 set，有 3 个字节，$4 name 表示这个key有4个字节， key 名为 name， $9 kwingtaai 表示这个key对应的值有9个字节， 值为 kwingtaai
三种回写策略
回写策略，对应着 AOF 的机制中 appendfsync 配置项，即always、everysec、no。
Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
上面说到， AOF 日志是为了找回故障丢失的数据，那么以上三种回写策略是否可以完美的解决这个问题呢？又是否会造成主线程阻塞呢？
“同步写回”可以做到基本不丢数据，但是它在每一个写命令后都有一个慢速的落盘操作，不可避免地会影响主线程性能；虽然“操作系统控制的写回”在写完缓冲区后，就可以继续执行后续的命令，但是落盘的时机已经不在 Redis 手中了，只要 AOF 记录没有写回磁盘，一旦宕机对应的数据就丢失了；“每秒写回”采用一秒写回一次的频率，避免了“同步写回”的性能开销，虽然减少了对系统性能的影响，但是如果发生宕机，上一秒内未落盘的命令操作仍然会丢失。所以，这只能算是，在避免影响主线程性能和避免数据丢失两者间取了个折中。
AOF重写机制
为了将日志文件变小，AOF 提供了重写机制，就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。比如说，当读取了键值对“testkey”: “testvalue”之后，重写机制会记录 set testkey testvalue 这条命令。这样，当需要恢复时，可以重新执行该命令，实现“testkey”: “testvalue”的写入。
为什么重写机制可以把日志文件变小呢? 实际上，重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。我们知道，AOF 文件是以追加的方式，逐一记录接收到的写命令的。当一个键值对被多条写命令反复修改时，AOF 文件会记录相应的多条命令。但是，在重写的时候，是根据这个键值对当前的最新状态，为它生成对应的写入命令。这样一来，一个键值对在重写日志中只用一条命令就行了，而且，在日志恢复时，只用执行这条命令，就可以直接完成这个键值对的写入了。
AOF重写会阻塞吗
虽然 AOF 重写后，日志文件会缩小，但是，要把整个数据库的最新数据的操作日志都写回磁盘，仍然是一个非常耗时的过程。这时，我们就要继续关注另一个问题了：重写会不会阻塞主线程？
和 AOF 日志由主线程写回不同，重写过程是由后台子进程 bgrewriteaof 来完成的，这也是为了避免阻塞主线程，导致数据库性能下降。
