Redis持久化的两种机制（RDB和AOF）

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能。

RDB（Redis DataBase）

配置文件内默认的时RDB，一般情况下不需要修改这个配置。RDB是将支持当前数据的快照存成一个数据文件的持久化机制，在指定的时间间隔内将内存的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存里。

触发机制：

　　1.save的规则满足的情况下，会自动触发rdb规则

　　2.执行flushall命令，也会触发rdb规则

　　3.退出redis，也会产生rdb文件

触发后，备份会自动生成一个dump.rdb文件

优点：

　　1.适合大规模的数据恢复

　　2.对数据的完整性要求不高

缺点：

　　1.需要一定的时间间隔进程操作，如果redis意外宕机了，那么最后一次修改数据就没有了

　　2.fork进程的时候，会占用一定的空间内容，每次在保存RDB的时候，redis都要fork出一个子进程，并由子进程来进行实际的持久化工作，如果在数据集比较庞大时，fork可能会非常耗时，造成服务器在那么一瞬间会停止处理客户端

AOF（Append Only File）

Redis 默认不开启，需要在redis.config配置文件内手动开启（只需将appendonly改为yes），它的出现是为了弥补RDB的不足（数据的不一致性），它采用日志的形式来记录每个写操作，并追加到文件中，也就是将redis所有执行过的命令都记录下来（读操作不记录），会生成一个appendonly.aof文件，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作，即恢复的时候就把这个文件全部在执行一遍。

如果aof文件有错误，这时redis无法启动，需要修复这个aof文件，redis提供了一个工具redis-check-aof，此时只许在appendonly.aof文件所在的目录内执行redis-check-aof --fix appendonly.aof，如果文件正常，重启后就可以恢复。

优点：

　　1.每一次修复都同步，文件的完整性会更好

　　2.每秒同步一次，可能会丢失一秒的数据

　　3.从不同步，效率是最高的

缺点：

　　1.相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢

　　2.aof运行效率也要比rdb慢，所以redis默认的配置就是rdb持久化