Redis持久化之AOF（详解）

一、初识AOF

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

二、AOF特点

1、优势

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

2、劣势

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

三、AOF操作

1、概述

AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF默认不开启

可以在redis.conf中配置文件名称，默认为 appendonly.aof

AOF文件的保存路径，同RDB的路径一致。

AOF和RDB同时开启，redis听谁的？

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

RDB和AOF用哪个好

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

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，然后重新加载

AOF同步频率设置

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

• appendfsync everysec
  每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

• appendfsync no
  redis不主动进行同步，把同步时机交给操作系统。

2、正常恢复操作

1）配置中开启AOF

2）数据库中存值，并查看aof文件

3）文件正常，重启就可以恢复数据

3、异常恢复操作

1）配置中开启AOF

2）修复损坏AOF文件

四、总结