redis 持久化AOF

AOF 工作原理: 是将数据也是先存在内存，按照日志记录形式进行存储，在存储的时候会使用调用fsync来完成对本次写操作的日志记录，这个日志揭露文件其实是一个基于Redis网络交互协议的文本文件。AOF调用fsync也不是说全部都是无阻塞的，在某些系统上可能出现fsync阻塞进程的情况，对于这种情况可以通过配置修改，但默认情况不要修改。AOF最关键的配置就是关于调用fsync追加日志文件的平率，有两种预设频率，always每次记录进来都添加，everysecond 每秒添加一次。两个配置各有所长后面分析。由于是采用日志追加的方式来持久话数据，所以引出了第二个日志的概念：rewrite（下面会介绍）

将appendonly改为yes，默认是no，改为yes开启AOF持久化，存储的文件名默认是appendonly.aof

暂时将rdb持久化文件干掉

放入一些数据

查看appendonly.aof文件内容，证明开启AOF持久化会如实记录所有的写操作（读不管）。

127.0.0.1:6379> set k11 k11
OK
127.0.0.1:6379> shutdown
not connected> exit

查看dump.rdb

RDB持久化也可以。说明RDB和AOF是可以共存的

现在我们把appendonly.aof数据损坏搞乱，看是否可以启动redis。看加载的顺序。如果可以证明加载的dump.rdb,如果不可以说明加载的appendonly.aof

启动redis

可以看到已经启动不了redis，说明RDB和AOF是可以共存，并且是找到的AOF

我们再来看目录

可以看到有redis-check-aof   当数据损坏的时候redis已经为我们想好了解决方案，我们可以使用redis-check-aof进行修复。它会将不符合redis语法或错误的信息进行修复

redis-check-aof --fix appendonly.aof

举一反三，如果dump.rdb有损坏，也可以使用redis-check-rdb进行修复

再次启动redis

成功

持久化AOF与RDB也有共同特点，都有自己的存储方式，rdb 有save 900 1，save 300 10，save 60 10000.

AOF也有几种方式，appendfsync的3种：always everysec和no

always:同步持久化磁盘，只要有更变立即记录到磁盘，性能较差但数据完整性比较好

everysec:出厂默认推荐。每秒记录一次，异步记录，如果一秒内出现宕机，数据会丢失

no：写入aof文件，不等待磁盘同步

AOF 采用文件追加方式，文件肯定会越来越大，为了避免此种情况，redis增加了rewrite重写机制，当达到一定的阈值后，就会触发重写机制。启动内容压缩，说白了就是一些重复的命令可以适当丢弃等。如果只保留可以恢复数据的最小指令集，可以使用bgrewriteaof命令

重写的原理，当到达一定的大小时，redis就会启动。aof文件持续增大，会fork出一条新进程来进行文件重写，遍历新进程的内存中数据，每条记录有set的语句，重写aof文件的操作，并没有读取旧的aof文件，而是将新进程的内存数据内容用命令的方式重写了一个新的aof文件。幽默点说就是瘦身计划，当一个女孩子照镜子发现稍微有点胖乎乎的状态，立刻启动瘦身计划，直接将发胖杀死在萌芽状态。

触发的时机：redis会记录上次重写的AOF大小，默认的配置是当AOF文件大小时上次rewrite文件大小的一倍并且大于64M触发

一般实际中不会设置成64M这么小，几下就满了。实际中一般是以G为单位

配置文件位置：