04 | AOF日志：宕机了，Redis如何避免数据丢失？

---

Redis核心技术与实战

基础篇

04 | AOF日志：宕机了，Redis如何避免数据丢失？

AOF 日志是如何实现的？

AOF（Append Only File）日志是写后日志，“写后”的意思是 Redis 是先执行命令，把数据写入内存，然后才记录日志。

AOF 里记录的内容

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

AOF 为什么要先执行命令再记日志？

• 为了避免额外的检查开销，Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。而写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。所以，Redis 使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。
• AOF 是在命令执行后才记录日志，所以不会阻塞当前的写操作。

AOF 的两个潜在的风险

• 如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。
• AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。 这是因为，AOF 日志也是在主线程中执行的 （写回策略为 Always 时），如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行。

以上两个风险都和 AOF 写回磁盘的时机相关。

三种写回策略

AOF 机制提供了三个选择，也就是 AOF 配置项 appendfsync 的三个可选值。

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

针对避免主线程阻塞和减少数据丢失问题，这三种写回策略都无法做到两全其美。

• “同步写回”可以做到基本不丢数据，但是它在每一个写命令后都有一个慢速的落盘操作，不可避免地会影响主线程性能；
• 虽然“操作系统控制的写回”在写完缓冲区后，就可以继续执行后续的命令，但是落盘的时机已经不在 Redis 手中了，只要 AOF 记录没有写回磁盘，一旦宕机对应的数据就丢失了；
• “每秒写回”采用一秒写回一次的频率，避免了“同步写回”的性能开销，虽然减少了对系统性能的影响，但是如果发生宕机，上一秒内未落盘的命令操作仍然会丢失。所以，这只能算是，在避免影响主线程性能和避免数据丢失两者间取了个折中。

AOF 是以文件的形式在记录接收到的所有写命令，随着接收的写命令越来越多，AOF 文件会越来越大，AOF 文件过大将会带来性能问题。

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

日志文件太大了怎么办？

AOF 重写机制就是在重写时，Redis 根据数据库的现状创建一个新的 AOF 文件，也就是说，读取数据库中的所有键值对，然后对每一个键值对用一条命令记录它的写入。比如说，当读取了键值对 “testkey”: “testvalue” 之后，重写机制会记录 set testkey testvalue 这条命令。这样，当需要恢复时，可以重新执行该命令，实现 “testkey”: “testvalue” 的写入。

疑问：为什么重写机制可以把日志文件变小?

重写机制具有 “多变一” 功能。所谓的“多变一”，也就是说，正在使用的 AOF 日志中的多条命令，在重写后的新日志中变成了一条命令。因为当一个键值对被多条写命令反复修改时，AOF 日志会记录相应的多条命令。但是，在重写的时候，是根据这个键值对当前的最新状态，为它生成对应的写入命令。

AOF 重写会阻塞吗?

和 AOF 日志由主线程写回不同，重写过程由后台子进程 bgrewriteaof 来完成，为了避免阻塞主线程，导致数据库性能下降。

fork 子进程时，子进程会拷贝父进程的页表，即虚实映射关系（逻辑地址和物理地址的映射关系），而不会拷贝物理内存，所以不会阻塞。子进程复制了父进程页表，因此能访问父进程的内存数据，相当于有了父进程的所有内存数据。

每个进程默认只有一个线程，一般称为主线程，可以通过 Pthread_create 创建子线程，子线程与主线程严格来说是平等关系，它们都是该进程下的逻辑流，共享进程资源。所以这里指的是 Redis 用于网络 io 和处理请求的线程 fork 了一个子进程。

重写的过程可以总结为 “一个拷贝，两处日志”。

• “一个拷贝” 就是指，每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。
• “第一处日志” 就是指正在使用的 AOF 日志（严格地说是指写回后的日志文件）。在 AOF 重写过程中，当系统宕机了，Redis 可以借助正在使用的 AOF 日志把内存（AOF 重写缓冲）恢复到宕机前的状态。
• “第二处日志” 就是指新的 AOF 重写日志（严格地说是指 AOF 重写缓冲）。等到拷贝数据的所有操作记录重写完成后，重写日志记录的这些最新操作也会写入新的 AOF 文件，以保证数据库最新状态的记录。此时，就可以用重写 AOF 日志替代正在使用的 AOF 日志。
  

总结来说，每次 AOF 重写时，Redis 会先执行一个内存拷贝，用于重写；然后，使用两处日志保证在重写过程中，新写入的数据不会丢失。而且，因为 Redis 采用额外的线程进行数据重写，所以 AOF 重写过程并不会阻塞主线程（磁盘压力不大的情况）。

注意：如果 AOF 重写子进程的写入量比较大，fsync 线程会被阻塞，进而阻塞主线程(主线程会监控 fsync 的执行进度)。