redis是内存数据库，数据时存储在内存中的，当程序down后，数据也随之消失，因此，在很多情况下，我们需要对redis做持久化操作
redis持久化方式有2种：
- RDB方式
- AOF方式
AOF是什么？
AOF：Append Only File，以日志的形式来记录每个写操作（增量保存），将redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以写改文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话，就根据日志文件的内容将写指令从前到后执行一次，以完成数据的恢复工作。
注意：AOF不仅会记录数据，还会记录写操作。
AOF流程
1、客户端的请求写命令会被append追加到AOF缓冲区内
2、AOF缓冲区根据AOF持久化策略【always/everysec/no】将操作sync同步到磁盘的AOF文件中
3、AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量
4、redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的
AOF优势与劣势
优势：
- 备份机制更稳健，丢失数据概率更低
- 可读的日志文本，通过操作AOF文件，可以处理误操作
劣势：
- 比起RDB占用更多的磁盘空间
- 恢复备份速度要慢
- 每次读写都同步的话，有一定的性能压力（每次写都记录）
- 存在个别bug，造成不能恢复
开启AOF
在redis.conf中修改：appendonly yes
文件名：
注意：当开启AOF时，RDB会默认关闭，自动加载AOF
AOF异常修复
异常修复：表示redis在运行过程中，AOF文件突然损坏了，我们需要及时修复，当AOF文件受损时，我们启动会出现以下问题：
修复步骤：
- 在redis中的bin目录下，找到 redis-check-aof
- 输入以下指令进行修复：
redis-check-aof --fix appendonly.aof如：
AOF同步频率设置
在redis.conf中，有以下配置：
1、 appendfsync always
始终同步，每次redis的写入都会立刻记入日志；
性能较差但数据完整性比较好
2、appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
3、appendfsync no
redis不主动进行同步，把同步时机交给操作系统
AOF的Rewrite 压缩操作（重写压缩）
1、Rewrite压缩是什么？
AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bfrewriteaof
- 最小指令集，案例如下：
原来的指令：
set a1 50
set a1 100
set a2 30
set a2 200
压缩的最小指令：
set a1 100 a2 200
2、重写原理，如何实现重写
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后在rename），redis4.0版本后的重写，是指把rdb快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换原来的流水账操作。
no-appendfsync-on-rewrite：yes
