Redis持久化之AOF

Redis是一个基于内存的数据库，内存的超强计算能力能为Redis提供优越的性能，但是也带来一个问题内存断电即失，不能做到磁盘的永久保存，这时需要借助一些特殊的持久化手段如AOF（Append Only File）和RDB，今天先来聊聊AOF基于增量日志的持久化机制。

AOF持久化体验

Redis默认的持久化机制是RDB，我们如果想体验AOF持久化机制，需要修改redis.conf文件，开启AOF持久化，将配置值改为yes

AOF持久化写回策略，测试定义每秒写入，也是生产推荐使用方式

修改完毕重启redis，就是AOF持久化方式，这时在redis中操作的命令会以每秒为单位追加写入到appendonly.aof文件中，appendonly.aof文件中的命令记录的是每条sql执行的命令如下所示

AOF日志格式解析如下

AOF日志是如何实现的

AOF日志一般为写后日志，也就是说是命令正确执行完毕后将命令写入日志文件中，这样做有如下好处

• 命令写入日志文件不需要进行额外的格式校验，如果命令格式错误那么不会写入日志文件中，这样就保证了后续redis根据AOF文件恢复数据，不会有执行错误的风险。
• 命令执行完后才记录日志，那么不会阻塞当前的写操作。

AOF这种写入方式会存在一定的风险

• 如果刚执行完一个命令后，机器宕机那么这个命令还未保存到日志文件中，后续redis从AOF文件中恢复就会缺少数据，所以redis不能保证数据库和日志文件完全一致。
• AOF虽然用写后日志的形式避免了当前的写操作，但这会给下一个操作带来阻塞的风险，因为AOF的写操作在主线程中执行，如果在将命令写入日志文件中时磁盘的写压力大，就会导致写盘慢，从而阻塞主线处理其他业务。

AOF的风险都来自于日志写入的时机，那么怎么控制AOF写入日志文件时机呢？写回策略由appendfsync参数控制

写回策略

• always：同步写回，每个写命令执行完后，立马同步将日志写入磁盘
• everysec：每秒写回，每个写命令执行完，先将日志写入AOF文件的内存缓冲区，每隔一秒把缓冲区内容写入日志文件中。
• no：操作系统控制写回，每个写命令执行完，先将日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘（写回磁盘不受redis控制）。

这三种写回策略都是不完美的，都不能彻底解决数据丢失和主线程阻塞问题，我们在开发中需要在性能和可靠性之间进行取舍，三种写回策略对比如下

在redis.conf文件中默认配置的是everysec，生产中无特殊要求也是使用everysec，因为everysec写回策略在可靠性和性能上都是比较折中的。

AOF重写机制

AOF只是设置写回策略是远远不够的，因为AOF默认追加的文件都是定义的appendonly.aof，如果日志文件过大，那么就会导致一系列的性能问题如

• 文件系统本身对文件大小有限制，无法保存过大的文件。
• 如果文件太大，后续往日志文件中追加内容效率将会降低。
• 如果发生宕机，利用AOF文件恢复需要的时间长，恢复时间长影响redis正常使用。

所以我们需要将AOF文件”瘦身“，AOF重写机制就是在重写时Redis根据数据库的现状创建一个新的AOF文件，因为AOF对每一条命令记录日志，那么多条日志命令产生的影响对现有数据库而言可以进行简单合并，如下图所示。

Redis顺序执行的命令，产生的最终结果为【“N”，“M”，“D”】那么redis重写后的日志文件只需要能够保存最终结果的列表即可，所以就能将图中的六条命令合并为一条命令LPUSH test D M N，这样就能让AOF文件内容得到精简，从而达到重写AOF文件的目的。

AOF重写细节

AOF重写需要将整个数据库最新的操作日志写入到磁盘中，这么一个耗时的操作是否会阻塞主线程呢？显然Redis不会让这种情况产生，==在重写时Redis会fork一个子进程bgrewiteaof==，避免重写操作阻塞主线程（虽然fork后不会阻塞主线程但fork的一瞬间是会阻塞子线程的，fork不会复制主线程所有的数据只会拷贝需要的数据结构，这个拷贝是非常耗时的会阻塞主线程，阻塞时间取决于实例的大小）。

重写的过程主要概括为一个拷贝两个日志。

一个拷贝指的是，父进程fork一个子进程也就是bgrewiteaof，这时并不会将父进程的内存全部复制给bgrewiteaof，而是子进程会拷贝父进程的页表即虚实映射关系，并不会做物理拷贝，子线程复制了父进程页表后，就能和父进程共享内存数据，只有当存在写操作时才会真正做物理拷贝（这个地方可以完全参考COW理解，只有真正写入时才需要复制数据，单纯的读可以共享数据）。

两个日志都为AOF追加日志一个为正在使用的AOF日志一个为重写新增的AOF日志。

• 因为主线程未阻塞，所以在处理请求后会将日志写入到正在使用的AOF日志缓冲区中，等待日志回写时落盘。
• 新增的重写日志也需要将处理请求的日志写入新增日志缓冲区，这样保证了重写后的日志依然是完整的，不会丢失数据。

等待所有的重写操作完成我们就可以使用新的AOF文件代替旧的AOF日志文件了。

AOF重写配置

想要AOF重写有两种方法手动和自动

• 手动的就是执行bgrewriteaof指令，手动重写AOF文件，重写会创建一个当前 AOF 文件的体积优化版本。
• 自动执行需要配置参数
• auto-aof-rewrite-min-size: 表示运行AOF重写时文件的最小大小，默认为64MB。
• auto-aof-rewrite-percentage: 当前AOF文件比上一次重写后AOF文件的增量大小，和上一次重写后AOF文件大小的比值。