Redis持久化之RDB和AOF

redis持久化之RDB

---

---

前言

持久化就是在指定时间间隔内将内存中的数据集快照写进磁盘，也就是行话讲的snapshot快照，它恢复时将快照文件直接读进内存中。

---

一、RDB(Redis DataBase)

1.介绍

Redis会单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替代上次持久化好的文件，整个过程中，主进程是不进行任何IO操作，这就保持了极高的性能。如果需要进行大规模数据的回复，且对于数据恢复的完整性是不敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化后的数据可能丢失。

2.Fork

复制一个当前进程的子进程，与原进程基本一致

3.动态停止RDB的命令

redis-cli config set save

4.关于RDB缓存的一些配置问题

4.1配置文件位置以及文件名

4.2快照触发条件

4.3dump.rdb如何载入redis

在启动redis-server前，将运维部门传过来的dump.rdb文件备份复制到dump.rdb中，再执行命令。

5.优点

适合大规模的数据恢复，对数据完整性和一致性的要求不高

6.缺点

在一定时间间隔内做一次备份，所以如果redis意外down掉，就会丢失最后一次快照后的所有修改。
此外fork操作时，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

二、AOF(Append Only File)

1.介绍

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

2.AOF的配置文件

2.1默认为no

yes打开持久化

2.2默认名字

2.3Appendfsync(三种模式)

Always:同步持久化，数据一改变就立即记录到磁盘，性能较差但是数据完整性好
Everysec:默认，异步操作，每秒记录，但是一秒内宕机会丢失数据
no:

2.4no-Appendfsync-on-rewrite

重写时是否可以运用Appendfsync，用默认的no即可，保证数据安全性。

3.AOF和RDB同时存在

两者同时存在时，启动redis时先加载aof

4.AOF文件出现问题(语法)时

利用redis-check-aof文件来修正aof文件，命令为:

	redis-check-aof --fix appendonly.aof

4.Rewrite

4.1介绍

由于AOF采用文件追加方式，为了避免此方式导致的文件越来越大问题，新增了重写机制，当AOF文件大小超过所设定的阈值时，Redis就会启动ADF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

4.2重写原理

AOF文件持续增长过大时，会fork出一条新进程来将文件重写（也是写临时文件在rename），遍历新进程的内存中数据，每条记录有一条set语句。重写aof文件的操作，并没有读取旧的文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，与快照类似。

4.1触发机制

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

总结