Redis持久化之AOF(Append Only File)

Redis持久化之AOF(Append Only File)

Redis是一个基于内存的数据库，它的数据是存放在内存中，内存有个问题就是关闭服务或者断电会丢失。

Redis的数据也支持写到硬盘中，这个过程就叫做持久化。

Redis提供了2种不同形式的持久化方式。

• RDB（Redis DataBase）
• AOP（Append Of File）

AOF（Append Only File）

AOF是什么？

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

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是键快照文件直接读到内存里。

AOF持久化流程

• 客户端的请求写命令会被append追加到AOF缓冲区内
• AOF缓冲区会根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中
• AOF文件大小超过重写策略或手动重写时，会对AOF文件进行重写（rewrite），压缩AOF文件容量
• redis服务器重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

AOF如何开启

可以在redis.conf文件中对AOF进行配置：

appendonly no # 是否开启AOF，yes：开启，no：不开启，默认为no
appendfilename "appendonly.aof" # aof文件名称，默认为appendonly.aof
dir ./  # aof文件所在目录，默认./，表示执行启动命令时所在的目录，比如我们在/opt目录中，去执行redis-server /etc/redis.conf 来启动redis，那么dir此时就是/opt目录

AOF和RDB同时开启，怎么办？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

AOF启动/修复/恢复

• AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
• 正常恢复
  • 修改默认的appendonly no，改为yes
  • 将有数据的aof文件复制一份保存到对应的目录（查看目录：config get dir）
  • 恢复：重启redis然后重新加载
• 异常恢复
  • 修改默认的appendonly no，改为yes
  • 如遇到aof文件损坏，通过/usr/local/bin/redis-check-aof --fix appendonly.aof进行恢复

AOF同步频率设置

可以在redis.config中配置AOF同步的频率，如下：

appendfsync always：每次写入立即同步

始终同步，每次redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec：每秒同步

每秒同步，每秒记录日志一次，如果宕机，本秒数据可能丢失；更新的命令会放在内存中AOF缓冲区，每秒将缓冲区的命令追加到AOF文件

appendfsync no：不主动同步

redis不主动进行同步，把同步交给操作系统

rewrite压缩（AOF文件压缩）

rewrite压缩是什么？

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

重写原理，如何实现重写？

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件，最后在rename替换旧文件），redis4.0版本后的重写，是指就把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

触发机制，何时重写？

• bgrewriteaof：手动触发重写

  从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， bgrewriteaof 仅仅用于手动触发重写操作。

  redis会记录上次重写的aof大小，默认配置是当aof文件大小是上次rewrite后大小的2倍且文件大于64M时触发。

  重写虽然可以节约大量磁盘空间，减少恢复时间，但是每次重写还是有一定负担的，因此设置redis满足一定条件才会进行重新。

• auto-aof-rewrite-percentage：设置重写基准值

  设置重写的基准值，默认100，当文件达到100%时开始重写（文件是原来重写后文件的2倍时重写）。

• auto-aof-rewrite-min-size：设置重写基准值

  设置重写的基准值，默认64MB，AOF文件大小超过这个值开始重写。

• 举个例子

  文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

  系统载入时或者上次重写完毕时，redis会记录此时AOF大小，设置base_size。

  如果Redis的AOF当前大小>=base_size+base_size*100%(auto-aof-rewrite-percentage默认值) 且 当前大小>=64mb(auto-aof-rewrite-min-size默认值)的情况下，redis会对AOF进行重写。

重写流程

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

• 手动执行bgrewriteaof命令触发重写，判断是否当前有bgfsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行
• 主进程fork出子进程执行重写操作，保证主进程不会阻塞
• 子进程遍历redis内存中的数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整性以及新AOF文件生成期间的新的数据修改动作不会丢失
• 子进程写完新的AOF文件后，向主进程发送信号，父进程更新统计信息
• 主进程把aof_rewrite_buf中的数据写入到新的AOF文件
• 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写

no-appendfsync-on-rewrite：重写时，不会执行appendfsync操作

该参数表示在正在进行AOF重写时不会将AOF缓冲区中的数据同步到旧的AOF文件磁盘，也就是说在进行AOF重写的时候，如果此时有写操作进俩，此时写操作的命令会放在aof_buf缓存中（内存中），而不会将其追加到旧的AOF文件中，这么做是为了避免同时写旧的AOF文件和新的AOF文件对磁盘产生的压力。

默认是ON，表示关闭，即在AOF重写时，会对AOF缓冲区中的数据做同步磁盘操作，这在很大程度上保证了数据的安全性。

但在数据量很大的场景，因为两者都会消耗磁盘IO，对磁盘的影响较大，可以将其设置为“yes”减轻磁盘压力，但在极端情况下可能丢失整个AOF重写期间的数据。

如果no-appendfsync-on-rewrite为yes，不写入aof文件，只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

如果no-appendfsync-on-rewrite为no，还是会把数据库往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

AOF优势

• 备份机制更稳健，丢失数据概率更低
• 可读的日志文本，通过操作AOF文件，可以处理误操作

AOF劣势

• 比RDB占用更多的磁盘空间
• 恢复备份速度要慢
• 每次读写都同步的话，有一定的性能压力
• 存在个别bug，造成不能恢复

AOF劣势

• AOF文件是一个只进行追加的日志文件
• Redis可以在AOF文件体积变得过大时，自动地在后台对AOF文件进行重写
• AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松。
• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
• 根据所使用的fsync策略，AOF的速度可能会慢于RDB

RDB与AOF

• 官方推荐2个都启用。
• 如果对数据不敏感，可以单独用RDB。
• 不建议单独使用AOF，因为可能会出现BUG。
• 如果只是做纯内存缓存，可以都不用。

抄自官网

• RDB持久化方式能够在指定的时间间隔对你的数据进行快照存储
• AOP持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始数据，AOF命令以redis协议追加保存每次写的操作到AOF文件末尾
• Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
• 只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式
• 同时开启两种持久化方式
• 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
• RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要要只是用AOF呢？
• 建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好北非），快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段
• 性能建议
  • 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这一条
  • 如果使用AOF，好处是在最恶劣的情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了
  • AOF的代价，一是带来持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据（aof_rewrite_buf）写到文件造成的阻塞几乎是不可避免的
  • 只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基数大小默认值64M（auto-aof-rewrite-min-size）太小了，可以设置到5G以上
  • 默认超过原大小100%（auto-aof-rewrite-percentage）大小时重写可以改到适当的数值。