Skip to content

1. AOF⚓

虽说 Redis 是内存数据库，但是它为数据的持久化提供了两个技术。分别是「AOF 日志和 RDB 快照」。

这两种技术都会用各用一个日志文件来记录信息，但是记录的内容是不同的。

  • AOF 文件的内容是操作命令；
  • RDB 文件的内容是二进制数据。

补充文章：Redis 设计与实现--AOF

1.1 AOF 日志⚓

若 Redis 每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里，然后重启 Redis 的时候，先去读取这个文件里的命令，并且执行它，就相当于恢复了缓存数据。这就是 Redis 里的 AOF(Append Only File) 持久化功能，注意只会记录写操作命令，读操作命令是不会被记录的，因为没意义。

AOF 持久化功能默认是不开启的，需要我们修改 redis.conf 配置文件中的以下参数：

appendonly            yes
appendfilename      "redis.aof"

记录在 AOF 日志里的内容如下图： 337021a153944fd0f964ca834e34d0f2

*3表示当前命令有三个部分，每部分都是以$+数字 开头，后面紧跟着具体的命令、键或值。然后，这里的「数字」表示这部分中的命令、键或值一共有多少字节。例如，「$3 set」表示这部分有 3 个字节，也就是「set」命令这个字符串的长度。

Redis 是先执行写操作命令后，然后才将该命令记录到 AOF 日志里，这么做其实有两个好处：

  • 第一个好处，避免额外的检查开销。 先执行写操作命令再记录日志的话，只有在该命令执行成功后，才将命令记录到 AOF 日志里，这样就保证记录在 AOF 日志里的命令都是可执行并且是正确的。
  • 第二个好处，不会阻塞当前写操作命令的执行。

潜在风险：

  • 执行写操作命令和记录日志是两个过程，那当 Redis 在还没来得及将命令写入到硬盘时，服务器发生宕机了，这个数据就会有丢失的风险。
  • 由于写操作命令执行成功后才记录到 AOF 日志，所以不会阻塞当前写操作命令的执行，但是可能会给「下一个」命令带来阻塞风险。 因为将命令写入到日志的这个操作也是在主进程完成的（执行命令也是在主进程），也就是说这两个操作是同步的。

1.2 三种写回策略⚓

4eeef4dd1bedd2ffe0b84d4eaa0dbdea

  1. Redis 执行完写操作命令后，会将命令追加到 server.aof_buf 缓冲区；
  2. 然后通过 write() 系统调用，将 aof_buf 缓冲区的数据写入到 AOF 文件，此时数据并没有写入到硬盘，而是拷贝到了内核缓冲区 page cache，等待内核将数据写入硬盘；
  3. 具体内核缓冲区的数据什么时候写入到硬盘，由内核决定。

在 redis.conf 配置文件中的 appendfsync 配置项可以有以下 3 种写回硬盘的策略，控制的就是上面说的第三步的过程：

  • Always，每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘；
  • Everysec，每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，然后每隔一秒将缓冲区里的内容写回到硬盘；默认值。
  • No，每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，再由操作系统决定何时将缓冲区内容写回硬盘。

这三种策略只是在控制 fsync() 函数的调用时机。

  • Always 策略就是每次写入 AOF 文件数据后，就执行 fsync() 函数；
  • Everysec 策略就会创建一个异步任务来执行 fsync() 函数；
  • No 策略就是永不执行 fsync() 函数;

1.3 AOF 重写⚓

Redis 为了避免 AOF 文件越写越大，提供了 AOF 重写机制，当 AOF 文件的大小超过所设定的阈值后，Redis 就会启用 AOF 重写机制，来压缩 AOF 文件。

AOF 重写机制是在重写时，读取当前数据库中的所有键值对，然后将每一个键值对用一条命令记录到「新的 AOF 文件」，等到全部记录完后，就将新的 AOF 文件替换掉现有的 AOF 文件。

重写机制的妙处在于，尽管某个键值对被多条写命令反复修改，最终也只需要根据这个「键值对」当前的最新状态，然后用一条命令去记录键值对。

如果直接使用现有的 AOF 文件进行重写的话，假如 AOF 重写过程中失败了，现有的 AOF 文件就会造成污染，可能无法用于恢复使用。

所以 AOF 重写过程，先重写到新的 AOF 文件，重写失败的话，就直接删除这个文件就好，不会对现有的 AOF 文件造成影响。

用命令手动重写： 

> BGREWRITEAOF

修改redis配置文件redis.conf，进行自动重写： 

auto-aof-rewrite-percentage 100 #增长百分比为100时开启重写（默认是100）

auto-aof-rewrite-min-size 64mb #当前aof文件大小大于这个值开启重写（默认是1M）

每次当serverCron（服务器周期性操作函数）函数执行时，它会检查以下条件是否全部满足，如果全部满足的话，就触发自动的AOF重写操作：

  • 没有BGSAVE命令（RDB持久化）/AOF持久化在执行；
  • 没有BGREWRITEAOF在进行；
  • 当前AOF文件大小要大于server.aof_rewrite_min_size（默认为1MB）(或者在redis.conf配置了auto-aof-rewrite-min-size大小)
  • 当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）

1.4 AOF 后台重写⚓

Redis 的重写 AOF 过程是很耗时的，所以由后台子进程 bgrewriteaof 来完成，这么做可以达到两个好处：

  • 子进程进行 AOF 重写期间，主进程可以继续处理命令请求，从而避免阻塞主进程；
  • 子进程带有主进程的数据副本，这里使用子进程而不是线程，因为如果是使用线程，多线程之间会共享内存，那么在修改共享内存数据的时候，需要通过加锁来保证数据的安全，而这样就会降低性能。而使用子进程，创建子进程时，父子进程是共享内存数据的，不过这个共享的内存只能以只读的方式，而当父子进程任意一方修改了该共享内存，就会发生「写时复制」，于是父子进程就有了独立的数据副本，就不用加锁来保证数据安全。

主进程在通过 fork 系统调用生成 bgrewriteaof 子进程时，操作系统会把主进程的页表复制一份给子进程，这个页表记录着虚拟地址和物理地址映射关系，而不会复制物理内存，也就是说，两者的虚拟空间不同，但其对应的物理空间是同一个，这样能够节约物理内存资源。，页表对应的页表项的属性会标记该物理内存的权限为只读。

不过，当父进程或者子进程在向这个内存发起写操作时，CPU 就会触发缺页中断，这个缺页中断是由于违反权限导致的，然后操作系统会在「缺页异常处理函数」里进行物理内存的复制，并重新设置其内存映射关系，将父子进程的内存读写权限设置为可读写，最后才会对内存进行写操作，这个过程被称为写时复制 (Copy On Write)。

所以，有两个阶段会导致阻塞父进程：

  • 创建子进程的途中，由于要复制父进程的页表等数据结构，阻塞的时间跟页表的大小有关，页表越大，阻塞的时间也越长；
  • 创建完子进程后，如果子进程或者父进程修改了共享数据，就会发生写时复制，这期间会拷贝物理内存，如果内存越大，自然阻塞的时间也越长；

如果重写过程中主进程修改了已经存在 key-value，就会发生写时复制，注意这里只会复制主进程修改的物理内存数据，没修改物理内存还是与子进程共享的。

所以如果这个阶段修改的是一个 bigkey，这时复制的物理内存数据的过程就会比较耗时，有阻塞主进程的风险。

1.5 AOF 重写时的一致性⚓

因为子进程在进行 AOF 重写期间， 主进程还需要继续处理命令， 而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

为了解决这个问题， Redis 增加了一个 AOF 重写缓存， 这个缓存在 fork 出子进程之后开始启用， Redis 主进程在接到新的写命令之后， 它会同时将这个写命令写入到AOF 缓冲区和AOF 重写缓冲区：

AOF 重写缓冲区

当子进程完成 AOF 重写工作（扫描数据库中所有数据，逐一把内存数据的键值对转换成一条命令，再将命令记录到重写日志）后，会向主进程发送一条信号，信号是进程间通讯的一种方式，且是异步的。

主进程收到该信号后，会调用一个信号处理函数，该函数主要做以下工作：

  • 将 AOF 重写缓冲区中的所有内容追加到新的 AOF 的文件中，使得新旧两个 AOF 文件所保存的数据库状态一致；
  • 新的 AOF 的文件进行改名，覆盖现有的 AOF 文件。

信号函数执行完后，主进程就可以继续像往常一样处理命令了。

在整个 AOF 后台重写过程中，会对主进程造成阻塞的情况：

  • 创建子进程的途中，复制父进程的页表等数据结构
  • 发生写时复制
  • 信号处理函数执行时也会对主进程造成阻塞