Redis持久化之AOF

RDB从整体上来说，已经很棒了，备份速度快，备份文件小，cpu性能也充足的用上了。但是最后的那一次备份是可能会丢失的。对于程序员来说，越是厉害的程序员强迫症越是强，不容有那么一点点瑕疵。所以为了解决数据最后一次备份可能会丢失的问题，Redis 开发社区的开发者门找到了一个解决办法，AOF模式持久化就随之而来。

AOF介绍

以日志的形式来记录每个写操作，将 Redis 执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis 启动之初会读取该文件重新构建数据，换言之，Redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

完整演示一遍 AOF 文件恢复

这里有一点值得注意，如果在服务开启期间，把 aof 的备份文件给删除了，那么在这段时间里，它不会重新生成 aof 备份文件。
只有重新关闭并开启服务，才能再次生成 aof 备份文件。

可见，选择几号库 ，并且设置 key 的命令和值都记录下来了。

注意点

1.AOF 模式会把用户的所有 写指令 都通过 append（最加内容到文件末尾） 方式记录到 aof 文件中（如果 redis 运行时，aof 文件被删除了，那么将不会起到备份的效果）。

2.FLUSHALL 和 FLUSHDB 都是写指令。

3.AOF 文件恢复的方式是，把 aof 备份文件里面的所有指令都逐行运行一遍，达到恢复数据的目的。

4.AOF 和 RDB 两种持久化方式是可以共存的。

aof 备份文件破损修复

AOF 备份文件模式

配置在 redis.conf 文件中。

appendfsync everysec

一共有三种模式：

• always：异步同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好。
• everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有一秒数据丢失。
• no：表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。

AOF 备份文件 Rewrite

aof 会逐条记录每一个写指令，那么就造成一个问题，在生产环境 aof 备份文件会在一两天内 飞速增长，会占用非常大的内存。

如：

INCR xxx
INCR xxx
INCR xxx
INCR xxx
... 一共十万条。

对，Redis 就是这么记录的。但是如果我们恢复数据后。xxx 的最终结果是 十万。
为什么不用下面的指令替代呢？？？

set xxx 100000

这样，就能够起到缩减 aof 备份文件大小的作用。

那么 redis 怎么做到这一点呢、？

redis 推出一个功能叫做 Rewrite。

Rewrite 介绍

AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof 强制进行后台重写 aof 备份文件。

重写原理

AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写（也是先写临时文件最后再 rename），遍历新进程的内存中数据，每条记录有一条的 set 语句。重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似。

触发机制

Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 Rewrite 后大小的一倍且文件大于 64 M时，触发。

在 redis.conf 文件里面就有配置。

auto-aof-rewrite-percentage 100

aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 64mb

设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。
如果是好一点的公司，这个值 3G 为起步设置，但是通常大规模应用这里设置为 6G，
当你看到你公司的 这个 值还是 64mb的 时候，你就能够知道这个公司的水平怎么样。

AOF 总结

• 相同数据集的数据而言， aof 文件要远大于 rdb 文件，恢复速度慢于 rdb 。
• aof 运行效率要慢于 rdb ，每秒同步策略效率较好，不同步效率和 rdb 相同。

另外：

1.RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储，速度快，性能高，但是会有几分钟左右的数据丢失。

2.AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以 Redis 协议追加保存每次写的操作到文件末尾，Redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积不至于过大。

3.只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

4.一般我们用 RDB 就好了，可能丢失那么几分钟数据也没什么。支付系统除外。

性能建议

因为 RDB 文件值用作后备用途，建议只在 Slave 上持久化 RDB 文件，而且只需要 15 分钟备份一次就够了，只保留 save 900 1 这条规则。

如果 Enable AOF ，好处是在恶劣的情况下只会丢失不超过两秒数据，启动脚本较简单只 load 自己的 AOF 文件就可以了。代价一是带来了持续的 IO，二是 AOF rewrite 的最后，将rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少 AOF rewrite 的频率，AOF 重写的基础大小值 64 M 太小了，可以设到 5G 以上。默认超过原大小 100% 大小时，重写可以改到适当的数值。

如果不 Enable AOF，仅靠 Master-Slave Replication 实现高可用性也可以。能省掉一大笔 IO 也减少了 rewrite 时带来的系统波动。代价是如果 Master/Slave 同时宕掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB 文件，载入较新的那个。新浪微博就选用了这种架构。