AOF机制

AOF是Redis提供的另外一种持久化的方式，它以独立日志的方式记录每次写入操作，重启时再重新执行这些操作，从而达到恢复数据的命令。

3.1执行原理

开启AOF机制后，所有的写入命令都会追加到aof_buf缓冲区中，并按照指定的策略定时将缓冲区中的数据同步到磁盘上。 AOF除了记录每条命令外，还会在适当的时候fork出一个子进程对AOF文件进行重写，在重写过程中，Redis会将可以合并的语句进行合并，将无效的语句进行删除，从而减小AOF文件的体积，以便减少文件的占用空间和方便在数据恢复时能够更快的进行加载。

3.2同步策略

Redis提供了三种同步策略，用于控制AOF缓冲区同步数据到磁盘上的行为，由参数 appendfsync 控制：

write和fsync操作说明：

• write操作会触发延迟写机制，Linux在内核提供页缓冲区用来提高硬盘的IO性能，write操作在写入系统缓冲区后直接返回。同步操作依赖于系统调度机制，例如缓冲区页空间写满或达到特定时间周期。 同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• fsync针对单个文件操作，做强制硬盘同步，fsync操作将阻塞直到写入硬盘完成后返回，它保证了数据持久化的安全。

Redis默认的同步机制为 everysec，此时能够兼顾性能和保证数据安全，在发生意外宕机的时，最多会丢失一秒的数据。

3.3相关配置

想要使用AOF功能，需要配置 appendonly 的值为 yes，默认值为 no。默认AOF的文件名为appendonly.aof,可以通过修改appendfilename 的值进行修改，和RDB文件的保存位置一样，默认保存在Redis的工作目录下。

四、对比分析

4.1优点与缺点

RDB的优点

• RDB使用一次性生成内存快照的方式， 产生的文件紧凑压缩比更高， 适用于备份和全量复制等场景。
• RDB文件通常比同一数据集的等效AOF文件小，所以使用RDB恢复数据远远快于AOF方式。
• RDB最大限度地提高了Redis的性能，因为Redis父进程只需要fork出一个子进程，它本生并不会执行磁盘I/O等操作。

RDB的缺点

• RDB方式没办法做到数据的实时持久化，假设每次持久化的时间间隔是5分钟，当在上一次持久化后3分钟后发生了服务宕机，则这三分钟内的数据会全部丢失。
• fork操作是一个重量级的操作，如果数据集很大，Fork操作可能会非常耗时。

AOF的优点

• AOF能够实现实时或秒级的持久化操作，能够保证数据的最少丢失。
• 如果突然宕机，日志以半写命令结束，可以使用redis-check-aof工具进行修复，从而保证数据最少丢失。

AOF的缺点

• AOF文件通常比同一数据集等效的RDB文件大。
• 根据选择的同步策略的不同，AOF可能比RDB还慢。

4.2使用建议

按照Redis官方的推荐，为保证的数据安全性，可以同时使用这两种持久化机制，在Redis官方的长期计划里面，未来可能会将AOF和RDB统一为单一持久化模型。需要注意的是，在这种情况下，当Redis重新启动时，Redis将使用AOF文件重建数据集，因为它可以保证数据的最少丢失。