Redis持久化：使用AOF

APPEND-ONLY FILE

命令写入过程

AOF文件

上一篇日志总结了Redis持久化方式中的RDB，它是Redis默认使用的持久化方式，使用RDB将数据持久化到磁盘的好处，可以对指定时间间隔内的数据备份，备份的数据只生成一个dump.rdb文件，备份时效率高，因为Redis主进程只需创建一个子进程来完成持久化任务，之后可以继续处理收到的其他命令。数据恢复速度快，简单，只需将dump.rdb文件复制到bin目录下，再重启Redis即可。缺点是如果对数据完整性和一致性有比较高的要求，那么RDB方式并不是十分适合，因为在定时进行持久化操作前系统出现问题崩溃了，那么没有来得及写入磁盘的数据都会丢失。在Redis持久化处理时我们有两种方案可以选择，RDB和AOF，AOF不是默认的选择，但是它可以弥补RDB在数据完整性和一致性方面的不足，这篇日志就来总结一下Redis持久化的第二种方式，AOF。

APPEND-ONLY FILE

AOF与RDB不同的是，AOF会将Redis的写入命令记录成日志文件，后面的写操作都会追加记录进来，数据恢复时，根据日志文件的内容将这些写命令按顺序从头到尾执行一次，这种方式比起RDB来说数据完整性和一致性更高。先来看下在Redis中启动AOF持久化操作：

和启动关闭RDB一样，使用CONFIG SET命令启用AOF持久化，然后可以用INFO PERSISTENCE命令查看AOF的启动状态，由上图可以看到，aof_enabled：1，证明启动成功，其次我们也可以直接ls –l查看目录下有没有生成appendonly.aof文件，有代表AOF启用成功。

命令写入过程

也就是说，当AOF功能启用时，Redis会在目录下创建一个AOF文件，相当于RDB文件，之后每当Redis接收到一个写入命令，对内存数据进行了修改，那么这条命令会append，拼接、追加到AOF文件中。对比起前面的RDB持久化，上一篇日志总结到，RDB持久化会在什么时候将内存数据保存到磁盘里dump.rdb文件中呢？这个参数我们可以自己设置，通过命令或者修改redis.conf文件中的SNAPSHOTTING参数，可以900秒内有超过一个键发生改变就进行一次写入，或300秒内有超过10个键发生改变就进行一次写入。

同理，AOF文件什么时候进行一次写入命令保存到AOF文件中呢？是每执行一条有实际修改内存数据的写入命令就立刻将命令保存到AOF文件里？在Redis执行一条写入命令后，会先将该命令保存到缓冲区中，当系统调用fsync（）函数后，缓冲区中的数据才会被写入磁盘，保存到appendonly.aof文件中。这个时机可以通过修改redis.conf文件中的APPEND ONLY MODE来设置：

可以看到此时的配置参数是appendonly no，意思是永不调用fsycn（），由系统来决定何时将命令数据从缓冲区写入到磁盘中。此外还有两个选项可以选择，appendonly always和appendonly everysec，前者表示对于Redis的每一个写入命令，执行完后都调用一次fsycn（）把数据写入磁盘，这样可以最大化确保数据不丢失，哪怕发生系统崩溃，丢失的也只是一次的写入操作。不过频繁调用fsycn（）明显是不合适的，因为这是一个阻塞操作，会让Redis服务器的性能明显下降。后者everysec表示每秒钟调用一次fsycn（），一秒钟可以做很多事情了，如果系统崩溃，丢失的是1秒的数据操作。

由此可见使用AOF优点是带来了更高的数据完整性，appendonly.aof文件中保存的是写入修改命令，清晰易懂。我们可以根据其完成数据的恢复。缺点是AOF文件随着不断写入，通常所占存储会大于RDB文件，且RDB文件存储的是数据备份，恢复时效率快，AOF文件由于存储的是命令，数据恢复时相当于在进行一次数据重建，效率比RDB慢。不光在数据恢复时AOF数据慢于RDB，在持久化方式运行时AOF的效率也要低于RDB，所以，在两者之中选择时，要看你是希望用放弃更高的数据完整性和一致性换取运行效率，还是希望放弃效率追求更高的安全性了，前者选用RDB，后者选用AOF。

AOF文件

按照惯例我们来看一下这个AOF文件，也就是写入命令append到的appendonly.aof文件里面都写了些什么，首先我们往Redis服务器里面执行几条SET命令修改数据：

然后用vim打开appendonly.aof文件，可以看到，里面有我们刚刚执行的SET命令，还有开头的一个SELECT，索引是0，表示的是选择索引为0的数据库，Redis数据库索引有0-15，默认从0开始。