Redis的两种持久化操作—RDB和AOF

Redis的两种持久化操作—RDB和AOF

---

---

一、RDB

1、什么是RDB？

含义：Redis数据备份文件，也被叫Redis数据集快照。
RDB(Redis DataBase Backup file)：在指定的时间间隔内将内存中的数据集快照（快照：某一时刻的数据集。可以用照片比较，把某一瞬间的东西记录下来）写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里。默认保存在当前的运行目录中，可以自己到redis的配置文件里面修改。

2、备份是如何执行的？

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写到一个临时文件中，等到持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，（意思是在fork子进程这个过程会阻塞主线程，但是在子进程写入RDB文件这个过程是不会阻塞主线程的），这就保持了极高的性能，如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是进行最后一次持久化的数据可能丢失。
fork：fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一样，但是是一个全新的进程，并作为原进程的子进程。

3、配置文件解析

---

（1）dump.rdb：在进行RDB持久化之后文件的默认名字，默认就叫dump.rdb。

（2）dir ./: dump.rdb文件的默认生成路径，默认是当前Redsi启动目录的生成路径，可以自己手动修改，在这里已经修改成了dir /usr/local/bin。

（3）stop-writes-on-bgsave-error ：当Redis无法写入磁盘的话（比如硬盘满了），直接关掉Redis的写操作，推荐yes。

（4）rdbcompression： 对于进行持久化的文件是否进行压缩存储，yes代表进行压缩。

（5）rdbchecksum：检查完整性，在持久化之前，对数据进行检验，看数据是否完整或者是否被损害，如果有，则不进行持久化，但是这样做会增加10%的性能消耗，如果希望获得到最大的性能提升，可以关闭此功能，推荐使用。

（6）save：秒钟写操作次数，手动持久化，下图的意思是如果在20秒内有三个key发生变化则进行持久化，save时只管保存，其他不管，全部阻塞，手动保存，不建议。

（7）bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户请求，可以通过lastsave命令获取最后一次成功执行快照的时间。

4、优势

1、适合大规模的数据恢复
2、对数据完整性和一致性要求不高更适合使用
3、节省磁盘空间
4、恢复速度快

5、劣势

1、Fork的时候，建立了一个临时文件来替换rdb文件，这个过程需要有两倍rdb文件的空间，就会浪费了这个空间。（特别是数据庞大时还是比较消耗性能）
2、在备份周期在一定间隔时间做一次备份，所以如果Redis在最后一次周期内意外down掉的话，就会丢失最后一次快照后的所有修改。

6、rdb文件的备份

1、先查看dump.rdb文件的大小

2、给Redis中添加数据

3、再查看dump.rdb文件中的数据大小

4、进行备份，先将dump.rdb复制一份

5、停止Redis，删除dump.rdb文件

6、恢复—把d.rdb文件名改为dump.rdb文件

7、启动Redis，再查看数据是否存在

二、AOF

1、什么是AOF？（Append Only File）

以日志的形式来记录每个写操作（增量保存），将Redis执行过的写命令记录下来（读操作不记录），只许追加文件但不可以改写文件（就是可以增加文件内容不可以改变文件内容），Redis启动的时候就会读取该文件重新构建数据，就是说，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2、AOF默认不开启

要使用AOF持久化操作，必须先去配置文件中开启AOF方式，可以在Redis中配置文件名称，默认文件名为：appendonly.aof，AOF文件的保存路径和RDB的路径一致。

这样就开启了AOF持久化方式。

3、如果AOF和RDB同时开启，Redis听谁的？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会丢失）

4、appendonly.aof的备份

过程和rdb文件一模一样。

5、异常恢复

如果在持久化过程中aof文件损坏了，或者里面的内容出了问题导致无法进行数据恢复，可以参考一下示例：
1、先看一下aof文件的内容：

2、在文件里面故意加一些内容，导致文件异常：

在文件加入了一个hello字符串；
3、停止Redis再重启：

重启之后再连接发现：

连接被拒绝了。
4、对aof文件进行修复：
使用redis-check-aof文件进行修复


输入修复命令之后，文件已经修复成功，再查看一下文件的内容：

发现hello已经不见了，再启动Redis：

成功启动。
总结：
1.如果遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复；
2.备份被写坏的AOF文件；
3.恢复：重启redis。然后重新加载。

6、AOF同步频率设置

在配置文件中有三个同步频率：
appendfsync always：始终同步，每次Redis的写入都会立刻记入日记；性能较差但是数据完整性较好。
appendfsync everysec：每秒同步，每秒记入日记一次，若果宕机，本秒的数据可能丢失。
appendfsync no：Redis不主动进行同步，把同步时机交给操作系统。

7、Rewrite重写压缩

（1）这是什么？
AOF采用文件追加的方式，文件会越来越大，为避免这种请况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。
（2）重写原理，如何实现重写？
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），Redis 4.0之后才有重写操作，就是把rdb的快照，以二进制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作，如：
原本数据的操作

压缩操作：

（3）重写压缩操作的触发机制（什么时候进行重写压缩？）
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
auto-aof-rewrite-percentage 100：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发），自己可以调整这个百分比。
auto-aof-rewrite-min-size：设置重写的基准值，最小文件64M，达到这个值开始重写。

三、AOF的持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略（always，everysec，no）将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略 或者手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；
优点：
1.备份机制更稳健，丢失数据概率更低。
2.可读的日志文件，通过操作AOF稳健，可以处理误操作。
缺点
1.比起RDB占用更多的磁盘空间。
2.恢复备份速度慢。
3.每次读写都同步的话，有一定的性能压力。
4.存在个别bug。

四、 总结：两个方式用哪个好？

官方推荐两个都启用；如果对数据不敏感，可以选单独用RDB；不建议单独用AOF，因为可能会出现bug；如果只是做纯内存缓存，可以都不用。