1.AOF是什么？
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
1.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的数据（数据不会存在丢失）
优势：
1. 备份机制更稳健，丢失数据概率更低。
2. 可读的日志文本，通过操作AOF稳健，可以处理误操作。
劣势：
1. 比起RDB占用更多的磁盘空间。
2. 恢复备份速度要慢。
3. 每次读写都同步的话，有一定的性能压力。
4. 存在个别Bug，造成恢复不能。
1.3 RDB和AOF用哪个好？
官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。
1. RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
2. AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
3. Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
4. 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
5. 同时开启两种持久化方式
6. 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
7. RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
8. 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
1.4 AOF启动——正常恢复
AOF的备份机制和性能虽然和RDB不同,但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
首先，修改redis.conf配置文件中的 appendonly no，改为yes。
然后，重启redis服务，就可以看到 appendonly.aof 文件已经生成了。
现在我向redis中写入4个数据，之后查看aof文件的大小。
下面，我先将appendonly.aof文件备份一份，然后将redis给shutdown。
之后，将原先AOF持久化的文件给删掉，将appendonly2.aof文件改名为appendonly.aof
之后，我们重启redis，看看其中都有哪些数据。可以看到之前设置的4个key仍然是存在的。这是因为redis重启之后，会去加载aof文件中的内容。
1.5 AOF启动——异常恢复
首先我们 vim appendonly.aof 这个文件，再最后一行加一个 hello，确保这个文件被修改了（即aof文件已损坏）。
然后重启redis。
在上图中可以看到，redis启动失败了。这是因为，redis在启动的时候会去加载你的aof文件，而我们刚刚将aof文件进行了随意修改，也就是说aof文件已经损坏了，那么此时redis就无法正常启动了。
解决方法：使用redis-check-aof --fix appendonly.aof 命令对该文件进行修复。
可以看到，修复完成之后，我们再次重启redis就成功了，并且其中的数据仍然存在。
1.6 AOF同步频率设置
appendfsync always：始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no：redis不主动进行同步，把同步时机交给操作系统。
1.7 AOF Rewrite压缩
