Redis 的数据持久化机制

Redis 的持久化主要有两大机制：AOF(Append Only File) 日志和 RDB 快照。

AOF

AOF 记录 Redis 的操作日志，它是在主线程中执行的。AOF 和数据库的写前日志(Write Ahead Log, WAL)不同，WAL 是在执行命令前先把修改的数据写到日志文件中，而 AOF 是在命令执行成功之后再记录日志，这样有两个好处：

1. 可以减少额外的检查命令是否正确的开销。
2. 因为是在命令执行后记录，所以不会阻塞当前的写操作。

AOF 日志的格式

AOF 中的命令是以文本形式记录的，以 “set testkey testvalue” 为例：Redis 会先以 *3 来表示当前命令有三个部分，每部分会先以 $+数字 来表示长度，然后跟上具体的命令、键或值。例如：

潜在风险

1. 可能在命令执行之后，写入 AOF 之前机器宕机，那么相应数据就有丢失的风险。
2. 上面说到 AOF 是在主线程执行的，如果磁盘写入很慢，那么就有可能阻塞下一个命令的执行。

写回策略

根据上述的潜在风险，Redis 提供了三种写回策略供用户评估选择，可以在 AOF 配置项 appendfsync 配置：

AOF 重写机制

背景

当 Redis 接收的命令越来越多，那么 AOF 文件就会越来越大，AOF 文件过大带来性能问题：

1. 文件系统本身对文件大小有限制，无法保存过大的文件；
2. 文件过大时，追加命令记录效率会变低；
3. 如果发生宕机，AOF 中的记录要一个个回放恢复数据，文件过大时会导致这个过程非常缓慢，影响 Redis 的正常使用。

重写机制

重写机制是指 Redis 会根据当前的数据状态创建一个新的 AOF 文件，即读取当前 Redis 中的所有的记录，将其一一写入新的 AOF 文件中。

为什么重写机制可以缩小 AOF 文件的大小呢？正常使用过程中，使用者可能会对一个 key 进行多次操作，而这些操作都会被记录到 AOF 中，而重写机制会忽略这些过程，只将最后的结果记录到 AOF 中，多条记录合并成了一条。

重写过程和 AOF 日志不同，它是由后台子进程 bgrewriteaof 来完成的，这样可以避免阻塞主线程导致的性能下降。

重写过程的主要流程如下：

1. 每次执行重写时，主线程会 fork 一个 bgrewiteaof 子进程，因为 fork 的特性，同时会把主进程的内存拷贝一份给子进程。
2. 因为此时主线程没有被阻塞，AOF 日志还会正常执行。
3. 主线程的操作还会被记录到重写缓冲区中，等拷贝数据重写完成后，重写缓冲区的日志也会被写入新的 AOF 文件，都完成后，新的 AOF 文件会替代就文件。