RDB持久化以及数据恢复

一、Redis DataBase

• RDB在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中。
• redis会单独创建fork子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。fork的作用是复制一个与当前进程一样的进程，新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
• 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。
• RDB的缺点是最后一次持久化的数据可能丢失。

二、配置的位置

RDB保存的是dump.rdb文件。dump.rdb备份文件一般会放在不同的机器上，用于发生意外时进行数据恢复。可以在redis.conf配置文件中对Snapshotting快照进行配置。

当我修改dump.rdb文件为dump_bk.rdb时，因为redis.conf配置文件中配置的是dump.rdb，所以重新启动redis服务器时找不到dump.rdb，也就无法恢复数据。

当我将dump_bk.rdb又修改回dump.rdb文件时，从新启动redis服务器就会从dump.rdb文件中读取上次备份的数据，用于数据的恢复。

三、触发RDB快照

• 使用配置文件中默认的快照配置，可以拷贝生成的dump.rdb文件用于恢复数据。
• 执行save或者bgsave可以立即进行备份，生成新的dump.rdb文件。save命令只管保存，其它不管，阻塞住其它全部操作。bgsave命令会使得redis在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
• 执行flushall命令也会产生dump.rdb文件，但是命令执行后数据清空，备份的也都是空数据，没有意义。

四、恢复数据

• 将备份文件dump.rdb文件移动到redis安装目录并启动服务，就会自动读取上一次的备份文件里面的数据。
• 执行config get dir可以获取目录的地址。

五、RDB优势

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

六、RDB劣势

• 在一定间隔时间做一次备份，所以如果redis发生意外，就会丢失最后一次快照后的所有修改。
• fork子进程执行的时候，内存中的数据被克隆了一份，大致2倍的膨胀性。

RDB总结：

• RDB是一个非常紧凑的文件。
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来完成，父进程不需要再做任何其它IO操作，所以RDB持久化的方式可以最大化redis的性能。
• 与AOF持久化方式相比，在恢复大规模的数据时，RDB方式会更快一些。
• RDB方式数据丢失的风险大，很可能会丢失最后一次备份以后又进行修改的数据，此时还来不及备份新修改的数据。
• RDB需要经常fork子进程来保存数据持久化到磁盘中，当数据比较大的时候，fork子进程也是非常耗时的，可能导致redis在一些毫秒级不能响应客户端的请求。