AOF记录内容

传统数据库的日志，例如 redo log（重做日志），记录的是修改后的数据，而 AOF 里记录的是 Redis 收到的每一条命令，这些命令是以文本形式保存的（类似mysql binlog中的statement格式）。

MySQL redo log是物理日志，记录的是某个数据页上做了什么修改；
MySQL binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”。

以Redis收到“set testkey testvalue”命令后记录的日志为例，看看AOF日志的内容。

redis开启日志 redis日志内容_Redis

其中，“*3”表示当前命令有三个部分。每部分都是由“$+数字”开头，后面紧跟着具体的命令、键或值，“数字”表示这部分中的命令、键或值一共有多少字节。例如，“$3 set”表示这部分有 3 个字节，也就是“set”命令。

写后日志的原因

AOF为写后日志:Redis先执行命令把数据写入内存，然后才记录日志。

redis开启日志 redis日志内容_数据_02

  • AOF写入不检查语法
    为了避免额外的检查开销，Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。
  • 不会阻塞当前写操作
    命令执行后才记录日志，故不会阻塞当前写操作。

风险点

  • 刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险
  • AOF虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险

写回策略

为了平衡数据丢失和操作阻塞的风险，需要平衡地选择策略。

AOF 机制提供了三个选择：

  1. Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
  2. Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
  3. No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

redis开启日志 redis日志内容_Redis_03

重写机制

原因

AOF是以文件的形式在记录接收到的所有写命令。随着接收的写命令越来越多，AOF文件会越来越大，会导致以下3点性能问题：

  1. 文件系统本身对文件大小有限制，无法保存过大的文件
  2. 如果文件太大，之后再往里面追加命令记录的话，效率也会变低
  3. 如果发生宕机，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用

AOF重写机制

AOF重写机制: 读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入,创建一个新的AOF文件。

旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。

redis开启日志 redis日志内容_子进程_04

AOF重写实现

每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两个日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用后台子进程bgrewriteaof进行数据重写，所以，这个过程并不会阻塞主线程。

过程：一个拷贝，两次日志

一个拷贝

每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

风险点
  • fork子进程阻塞

fork子进程，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中看到父进程重新申请了多大的内存空间。

两处日志

因为主线程未阻塞，仍然可以处理新来的操作。

第一处日志就是指正在使用的 AOF 日志，如果有写操作，Redis 会把这个操作写到它的缓冲区。这样一来，即使宕机了，这个 AOF 日志的操作仍然是齐全的，可以用于恢复。

第二处日志，就是指新的 AOF 重写日志。这个操作也会被写到重写日志的缓冲区。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，就可以用新的 AOF 文件替代旧文件。