Redis 中的数据持久化策略（AOF）

上一篇文章，咱们讲的是 Redis 的一种基于内存快照的持久化存储策略 RDB，本质上他就是让 redis fork 出一个子进程遍历咱们全部数据库中的字典，进行磁盘文件的写入。linux

但其实这种方式是有缺点的，先不说阻塞式 save 调用会阻塞整个 redis 服务，即使异步式 bgsave 也是基于时间间隔，每多少秒触发了多少次更新操做才会生成 RDB 文件，那么若是某次 RDB 生成以后，紧接着服务宕机，就至少丢失几秒甚至更多的数据，而且这些数据是没法挽回的。redis

而 AOF 是 redis 中的另外一种数据持久化策略，它基于操做日志，也是一个很优秀的持久化策略，固然也有缺点。那么本篇就来说讲这个 AOF 持久化策略。数据库

1、什么是 AOF 持久化策略

AOF 即 append only file，当 redis 采用这这种数据持久化策略的时候，每当 redis 服务器收到一条更新命令时，操做结束以后会将这条命令添加到 aof 内存缓冲区，特定的时间下刷新缓冲区到磁盘文件中，也就是咱们的 aof 文件。缓存

默认的 redis 启动配置文件中，会有这么两条配置：bash

appendonly 指定 redis 是否启用 AOF 持久化策略，appendfilename 指明生成的 AOF 文件名称。服务器

你也能够将 appendonly 选项指定为 yes，而后执行一条 set 命令，看看 redis 根目录下有没有生成一个 appendonly.aof 文件。markdown

redis.conf 中还有 appendfsync 这么一条配置，它指明 AOF 文件的写入频率，即使 linux 中文件 IO 使用的高效的 epoll，但每收到一条更新命令就进行一次文件 IO，未免也过低效，何况也不必。app

appendfsync 的配置项有如下三种值可选：异步

always：每一次系统 serverCorn 函数调用就刷新一次缓存区
everysec：每秒执行一次磁盘写入，期间全部的命令都会存储在 aof 缓存区
no：不作控制，任由操做系统决定何时刷新缓冲区

redis 默认配置是 everysec，即每秒刷新一次缓存区。函数

2、AOF 重写

因此，理论上来讲，随着 redis 服务器运行时间的持续，生成的 aof 文件只会愈来愈大，redis 提供 AOF 重写策略帮助优化和压缩 aof 文件。

好比：

set a "a"
set b "b"
set c "c"
del a
del b
复制代码

正常状况下，aof 文件中会保存着五条命令的 log，而后数据恢复的时候依次执行便可。而当你启动 AOF 重写后，实际上咱们的 aof 文件中只有 set c "c" 这一条命令的 log。

以上只是一个简单的示例，实际上 AOF 重写达到的效率比这优秀的多的多，每每能将几百条甚至几千条的命令日志，重写优化成个位数。带给咱们最直观的好处就是，aof 文件体积变小，数据恢复速度变快。

通常来讲，咱们能够经过向 redis 服务器发送 bgrewriteaof 命令触发服务器对 aof 文件进行重写，若是当前有正在运行的重写子进程，则本次重写会推迟执行，不然，直接触发一次重写。

除此以外，咱们还能够在配置文件中配置 aof 文件达到多大，自动触发文件重写。

由于 aof 文件重写同样是 fork 子进程并由子进程处理的，主进程依然提供服务，因此 redis 还提供一块重写缓冲区，当发现有子进程正在进行 aof 文件重写，最新的请求命令除了会添加到 AOF 缓冲区，还会添加进 AOF 重写缓冲区，当子进程完成重写任务后，主进程阻塞式将重写缓冲区的命令日志添加进最新的 aof 文件中。

看几条配置

no-appendfsync-on-rewrite 配置了当 redis 服务器由于某些状况即将阻塞（例如 save）时是否须要将缓冲区中的 aof 命令写入到磁盘，配置 yes 则每次遇到阻塞操做时刷新缓存到磁盘，配置为 no 则无需关心服务器阻不阻塞，缓存命令在缓存区。

auto-aof-rewrite-percentage 配置了当 aof 文件相较于上一版本的 aof 文件大小的百分比达到多少时触发 AOF 重写。举个例子，auto-aof-rewrite-percentage 选项配置为 100，上一版本的 aof 文件大小为 100M，那么当咱们的 aof 文件达到 200M 的时候，触发 AOF 重写。

auto-aof-rewite-min-size 配置了最小能容忍 aof 文件大小，超过这个大小必须进行 AOF 重写。

3、RDB 与 AOF

RDB 基于内存快照，有两种方式 save 和 bgsave，前者会阻塞 redis 服务，后者是异步 fork 子进程不影响主进程提供服务。大部分状况，咱们会经过配置时间间隔触发 RDB 文件写入。RDB 文件中保存的是 redis 内存中全部的数据一份快照。

优势是：

相同的数据量下，rdb 文件要小于 aof 文件，且恢复速度要快于 aof
rdb 文件中是整个数据的完整备份快照，数据存储紧凑即使不一样版本的 redis，也能顺利恢复
整个 rdb 持久化，只须要 fork 一个子进程进行持久化便可，父进程依然能够提供服务，效率最大化

缺点是：

容易丢失数据，即使配置了事件时间触发备份，也至少丢失一秒数据
若是数据量太大，fork 子进程的时候会阻塞毫秒级别时间

AOF 是基于命令操做日志，每条更新命令都会被刷到缓存区，而后在特定的时间节点被写入 aof 磁盘文件。

优势是：

相较于 RDB，AOF 数据可靠性更强，最多丢失一秒数据
数据库容错率变好，一些误操做能够经过直接改 aof 文件进行回退

缺点是：

AOF 文件一般较大且恢复效率比不上 RDB，不适合作数据冷备份

总的来讲，AOF 策略会使数据稳定性更高，具备更完整的数据备份，RDB 恢复效率高适合作灾难恢复，建议生产环境上二者都开启。

ps：Redis 官方号称后续出一个新的持久化策略，整合 RDB 和 AOF 提供更高效率的数据持久化，期待中。