持久化操作-AOF
AOF是什么？
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只允许加文 件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志 文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF持久化流程
- 客户端的请求写命令会被append追加到AOF缓冲区内。
- AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作同步到磁盘的AOF文件中。
- AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量。
- Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。
AOF默认不开启
可以在redis.conf中配置文件名称，默认为appendonly.aof。
AOF文件的保存路径，同RDB的路径一致。
如果AOF和RDB同时启动，Redis默认读取AOF的数据。
AOF启动/修复/恢复
- 正常恢复
- 启动：设置Yes：修改默认的appendonly no，改为yes。
- 恢复：重启Redis然后重新加载。
例：设置appendonly为yes，配置修改后，需要重启Redis服务。
服务器启动后，生成appendonly.aof文件，且大小为0。
设置数据。
set k11 v11
set k12 v12
set k13 v13
set k14 v14
set k15 v15
- 异常恢复
- 启动：设置Yes：修改默认的appendonly no，改为yes。
- 修复：如遇到AOF文件损坏，通过/user/local/bin/redis-check-aof --fix appendonly.aof进行 恢复。
- 恢复：重启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同步频率设置
-
appendfsync always
始终同步，每次Redis的写入都会立刻记入日志，性能较差但数据完整性比较好。
-
appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
-
appendfsync no
redis不主动进行同步，把同步时机交给操作系统。
Rewrite
-
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大 小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令 集。
例：设置k1为0，然后incr 进行了4次，k1对应的值会是4，其实就相当于set k1 4
-
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定 Redis要满足一定条件才会进行重写。
redis.conf默认配置
auto-aof-rewrite-min-size：表示重写时，文件大小必须必这个值要大。
auto-aof-rewrite-percentage：表示目前文件大小比上次重写后的文件大小大这么多才行。
