AOF日志是如何实现的？
注意点：AOF是写后(Redis 是先执行命令，把数据写入内存，然后才记录日志）日志,避免出现记录错误命令的情况。
AOF日志都记录了什么？
如上图，redis执行set testkey testvalue为例，“*”表示当前命令有三个部分，每部分都是由“$+数字”开头，后面紧跟着具体的命令、键或值。“数字”表示这部分中的命令、键或值一共有多少字节。
*3：执行的命令有3部分
$3：命令有3个字节
$7：键有7个字节
$9：值有9个字节
潜在风险？
因为AOF采用写后方式，存在以下场景：
- 如果命令执行后，还没写日志，Redis宕机了怎么办？
导致数据丢失。
- 如果命令执行后，还没写日志，Redis宕机了怎么办？
- 如果磁盘IO性能很慢，是不是就影响了后续操作？
导致主线程阻塞，影响后续操作无法执行。
- 如果磁盘IO性能很慢，是不是就影响了后续操作？
以上问题Redis提供了三种写回策略，便于根据实际场景选择。
AOF三种写回策略
- Always，同步写回(每个写命令执行完，立马同步地将日志写回磁盘)
- No，操作系统控制的写回(每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘)
- Everysec，每秒写回(每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘)
围绕两方面思考点出发，1.避免主线程阻塞 2.减少数据丢失，那这三种都无法做到两全其美。
- Always，同步写回。基本可以做到不丢失数据，但是它在每一个写命令后都有一个慢速的落盘操作，不可避免地会影响主线程性能；
- No，操作系统控制写回。落盘的时机在于操作系统，如果操作系统没执行写回就会导致数据全盘丢失。
-
Everysec，每秒写回。相比Always减少性能开销，不需要每一个命令都去写入磁盘。相比No，如果发生Redis宕机也只会丢失1秒数据，等于两者做了个折中处理。
写回策略优缺点对比
场景选择建议
- 获得高性能，选择No策略；
- 获得高可靠性保证，选择Always策略；
- 允许数据有一点丢失，性能不受太大影响，选择Everysec策略。
日志文件大了会有哪些影响？
需要注意的是如果随着时间和数据量的推移，日志文件会越来越过大，这会影响一些额外性能问题。
- 操作系统无法保存大日志文件
- 文件过大带随之写入的性能降低
- 恢复数据时，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果过大，Redis恢复时较慢
AOF重写机制
重写机制就是“多变一”(旧日志文件中的多条命令，在重写后的新日志中变成了一条命令)。如图：
重写会产生：一个拷贝两处日志(原日志和重写过程中的日志)
重写过程扩展阅读，这里需要慢慢消化了
主线程 fork 出后台的 bgrewriteaof 子进程，表面上来讲不会阻塞主线程，但是fork的瞬间会阻塞主线程。fork采用操作系统提供的写时复制(Copy On Write)机制，为了避免一次性拷贝大量内存数据给子进程造成的长时间阻塞问题，fork子进程需要拷贝必要的数据结构，其中一项就是拷贝内存页表(虚拟内存和物理内存的映射索引表)，拷贝过程会消耗大量CPU资源，拷贝中整个进程会阻塞，阻塞时间取决于整个实例的内存大小，实例越大，内存页表越大，fork阻塞时间越久。拷贝内存页表完成后，子进程与父进程指向相同的内存地址空间，虽然产生了子进程，但是并没有申请与父进程相同的内存大小。那什么时候父子进程才会真正内存分离呢？“写时复制”顾名思义，就是在写发生时，才真正拷贝内存真正的数据，这个过程中，父进程也可能会产生阻塞的风险。fork出的子进程指向与父进程相同的内存地址空间，此时子进程就可以执行AOF重写，把内存中的所有数据写入到AOF文件中。但是此时父进程依旧是会有流量写入的，如果父进程操作的是一个已经存在的key，那么这个时候父进程就会真正拷贝这个key对应的内存数据，申请新的内存空间，这样逐渐地，父子进程内存数据开始分离，父子进程逐渐拥有各自独立的内存空间。因为内存分配是以页为单位进行分配的，默认4k，如果父进程此时操作的是一个bigkey，重新申请大块内存耗时会变长，可能会产阻塞风险。另外，如果操作系统开启了内存大页机制(Huge Page，页面大小2M)，那么父进程申请内存时阻塞的概率将会大大提高，所以在Redis机器上需要关闭Huge Page机制。Redis每次fork生成RDB或AOF重写完成后，可以在Redis log中看到父进程重新申请了多大的内存空间。
Huge page对提升TLB命中率比较友好，因为在相同的内存容量下，使用huge page可以减少页表项，TLB就可以缓存更多的页表项，能减少TLB miss的开销。这个机制对于Redis这种喜欢用fork的系统来说，的确不太友好，尤其是在Redis的写入请求比较多的情况下。因为fork后，父进程修改数据采用写时复制，复制的粒度为一个内存页。如果只是修改一个256B的数据，父进程需要读原来的内存页，然后再映射到新的物理地址写入。一读一写会造成读写放大。如果内存页越大（例如2MB的大页），那么读写放大也就越严重，对Redis性能造成影响。
Huge page在实际使用Redis时是建议关掉的
