先写内存，在写日志。
1、命令执行成功才会被记录日志。
2、避免对当前命令的阻塞。
风险
1、突然宕机，Redis用作数据库的话，命令可能没有记入日志，所以就无法用日志进行恢复了。
2、AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为，AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。
3、子进程要拷贝父进程的页表，这个过程的耗时和 Redis 实例的内存大小有关。如果 Redis 实例内存大，页表就会大，fork 执行时间就长，可能阻塞主线程。
4、子进程和父进程共享内存。当主线程收到新写或修改的操作时，主线程会申请新的内存空间，用来保存新写或修改的数据，如果操作的是 bigkey，也就是数据量大的集合类型数据，那么，主线程会因为申请大空间而面临阻塞风险。
日志写回策略与选择
- Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
- Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
- No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
对比如下：
选择如下：
- 高性能，选择 No；
- 高可靠性，选择 Always；
- 允许数据丢失，同时性能较好，选择 Everysec。
重写机制
后台线程bgwriteaof读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。
作用
1、避免日志文件过大。
2、后台线程避免阻塞主线程
流程
一个拷贝，两处日志：AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用额外的线程进行数据重写，所以，这个过程并不会阻塞主线程
1、主线程 fork 出 bgrewriteaof 子进程，把主线程的内存拷贝一份给 bgrewriteaof 子进程
2、正在使用的 AOF 日志，因为可能记录了最新操作，Redis 会把这个操作写到它的缓冲区
3、这个操作也会被写到重写日志的缓冲区，重写日志也不会丢失最新的操作。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，我们就可以用新的 AOF 文件替代旧文件了。
