Redis：持久化之RDB和AOF

RDB（Redis DataBase）

　　在指定的时间间隔内将内存中的数据集快照写入硬盘

　　也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

　　Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

　　整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的回复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork

　　Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并做为原进程的子进程。

默认的save配置

1）15分钟一次

2）5分钟10次

3）1分钟 1万次

在redis.conf中

当满足上诉的更新次数时，rdb会自动备份到文件 dump.rdb 中

将dump.rdb移动至安装目录下启动服务可完成恢复

优缺点

优点：

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

　　2）对数据完整性和一致性要求不高

缺点：

　　1）在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

　　2）Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

如何停止

redis-cli config set save ""

AOF（Append Only File）

　　以日志的形式来记录每个写操作，将 Redis 执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的回复工作。

修改配置

　　默认情况下AOF是关闭的状态，在redis的配置文件中搜索Append快速定位到，进行修改为 yes

　　同时可以修改默认文件名（默认为：appendonly.aof）

　　Appendfsync：

　　　　1）Always：同步持久化，一步一写，性能较差，数据完整性高

　　　　2）everysec：出厂默认推荐，异步操作，每秒记录一次

　　　　3）NO

恢复同RDB，VIM可进去修改，但建议不要

修复aof文件

　　在安装目录下（删除不符合语法规范的）：　　redis-check-aof --fix aof文件

重写机制Rewrite什么时候触发:

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

优缺：

　　优点：

　　　　1）灵活的配置

　　缺点：

　　　　1）相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb

　　　　2）aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

总结：

1）RDB和AOF可以并存没毛病

2）如果只做缓存作用，可以不使用任何持久化方式

3）同时存在时，载入备份文件的优先级aof会高于rdb，因为aof相对比较完整

4）尽量不要只开启aof而关掉rdb，因为rdb更适合用于备份数据库（aof不断变化不好备份），快速重启不会有aof的潜在bug（指令语法错误），留着做个保障。