持久化操作-AOF

AOF是什么？

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

AOF持久化流程

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

AOF默认不开启

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

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

如果AOF和RDB同时启动，Redis默认读取AOF的数据。

AOF启动/修复/恢复

• 正常恢复
  1. 启动：设置Yes：修改默认的appendonly no，改为yes。
  2. 恢复：重启Redis然后重新加载。

例：设置appendonly为yes，配置修改后，需要重启Redis服务。

服务器启动后，生成appendonly.aof文件，且大小为0。

设置数据。

set k11 v11
set k12 v12
set k13 v13
set k14 v14
set k15 v15

• 异常恢复
  1. 启动：设置Yes：修改默认的appendonly no，改为yes。
  2. 修复：如遇到AOF文件损坏，通过/user/local/bin/redis-check-aof --fix appendonly.aof进行 恢复。
  3. 恢复：重启Redis然后重新加载。

例：服务启动和数据设置同上，模拟损坏appendonly.aof文件

vim appendonly.aof.1.incr.aof

在文件最后追加Hello World文本，破坏appendonly.aof原有格式，使其不可用。

重启Redis服务，并连接。由于aof文件被破坏，导致服务器启动失败。

通过/user/local/bin/redis-check-aof --fix工具对appendonly.aof进行恢复。

redis-check-aof --fix appendonlydir/appendonly.aof.1.incr.aof

修复成功。再次查看aof文件，破坏的地方已经修复。再次启动服务器成功。

AOF同步频率设置

1. appendfsync always

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

2. appendfsync everysec

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

3. appendfsync no

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

Rewrite

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

   例：设置k1为0，然后incr 进行了4次，k1对应的值会是4，其实就相当于set k1 4

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

   

   redis.conf默认配置

   auto-aof-rewrite-min-size：表示重写时，文件大小必须必这个值要大。

   auto-aof-rewrite-percentage：表示目前文件大小比上次重写后的文件大小大这么多才行。