Redis的持久化之AOF
Redis的两种持久化介绍
redis有两种持久化方式：RDB和AOF,RDB保存的是处理后的数据，AOF保存的是处理数据的指令。
AOF介绍
- 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读的操作不记录），只允许追加文件但不可以改写文件（实际上可以自己手动修改文件，但是如果失败会造成文件损坏）
- Redis启动之初就会读取该文件重新构造数据，也就是说如果Redis重启，那就根据备份的日志文件内容，将之前写的所有写操作从头到尾全部执行一遍，但也速度也因此要比RDB慢很多。
- 如果觉得繁琐的话可以简单理解为：类似于mysql保存的sql文件，我们需要恢复时只需要执行一遍文件里的指令即可。
AOF几个最常用配置
AOF的开启
AOF默认不开启，需要手动在配置文件中配置（如下图所示约1038行：appendonly no）
保存的文件
可以更改保存文件的名字，默认为appendonly.aof（如下图所示约1042行：appendfilename "appendonly.aof"），AOF方法的持久化文件保存的路径和RDB一样，在哪里开启服务就在哪里保存。
AOF文件恢复和备份
AOF的备份机制虽然和RDB有所不同，但是备份和恢复的操作都是一样的，都是需要备份时拷贝备份的文件，需要恢复时把备份的文件拷贝到Redis的工作目录下即可，重启Redis时都会自动加载。
AOF文件损坏
如果AOF文件损坏时，可使用redis-check-aof --fix appendonly.aof进行修复，不大建议使用，恢复成功率不高。
AOF的3种自动保存策略
- 始终同步，Redis的每次写操作都会立刻记录到日志中，但是比较耗性能（如下图所示约1067行：
appendfsync always） - 每秒同步，没秒写入一次日志，但是如果服务突然挂掉了的话，那该秒的数据可能丢失，但比RDB好一点点。（如下图所示约1068行：
appendfsync everysec） - 不主动进行同步，把同步交给操作系统（如下图所示约1069行：
appendfsync no）
ReWrite（重写）
AOF采用文件追加的方式，文件会越来越大，为了避免出现这种现象，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复文件的最小指令集（只生成构造该数据库及数据的命令，不会保留之前执行所有命令），可以使用命令bgrewriteaof开启。
Redis如何实现重写
AOF文件持续增长而过大时候，就会fork出一条新进程来讲文件重写（也就是先写临时文件在写rewite），遍历新进程的内存中的数据，每条记录都有一条set语句，重写AOF文件的操作，并没有读取旧的AOF操作，而是将整个内存中的数据库内容用命令的重新重写了一个新的AOF文件。
觉得繁琐的话可以理解为：AOF文件过大时候会分叉出一个子进程，这个子进程会扫描数据库的数据，然后只生成构造该数据库及数据的命令，不会保留之前执行所有命令，这点就完全与mysql保存的sql文件一样了。
何时进行重写
重写虽然可以节约大量的磁盘空间，减少恢复时间，但是每次重写都会有一定的负担，所以我们设定Redis需要满足一定条件才会进行重写。
重写条件（如下图所示约1109和1110行auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb）：系统载入时或者上次重写完毕时，Redis会记录AOF大小，设定为base_size，如果Redis的AOF单签大小>=base_size+base_size*100%(默认),且当前大小>=64mb的情况下Redis会对AOF进行重写。（简单来说就是文件大小大于等于64mb且文件大小是前一次保存大小的2倍）
优点
- 备份机制更稳健，丢失数据概率更低
- 可读的日志文本，通过操作AOF稳健，可以处理误操作（可编辑AOF文件）
缺点
- 比起RDB占用更多的磁盘空间
- 恢复备份速度更慢
- 每次读写都同步的haul，性能压力较大
- 存在个别bug的时候（aof文件编辑时候损坏了），恢复可能会失败