关于Redis中持久化机制RDB

引言：这是我参与新手入门的第2篇文章

Redis中有两种持久化方案，RDB（Redis DataBase）和AOF（Append Only File）。本文较为基础的讲解一下RDB的机制。
复制代码

RDB简介

RDB是什么？

RDB是Redis用来持久化的一种方式，其通过在指定时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将文件直接读取到内存中。

其备份是如何进行的

Redis 会单独创建（Fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换掉上次持久化的那个文件。 整个过程中主进程不进行任何IO操作，这确保了极高的性能。如果要进行大规模数据的恢复，而且对数据完整性不是那么敏感的话，RDB方式是个不错的选择，不过RDB最后一次持久化后的数据有可能会丢失。

如RDB还在进行持久化操作，并且已经备份到最后一次操作了，当RDB读取到一半的时候，Redis突然崩溃了，RDB无法从Redis中读取到数据，导致最后一次持久化的数据不完全。

RDB触发方式

RDB可以设置自动触发和手动触发（默认为自动触发）。

• save 该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。
• bgsave 执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

相关配置项

• save 默认设置是900秒内改动1次或者300秒内改动10次以及60秒内改动10000次就进行快照，当然可以自己设置。

• stop-writes-on-bgsave-error 默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

• rdbcompression 默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，Redis会采用LZF算法进行压缩（简单的说就是将相同类型的指令整合起来进行执行）。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

• rdbchecksum 默认为yes。存储快照后，数据库启动时候会判断快照是否损坏如果损坏则停止启动。这个可能会损失一部分性能，如果追求最高的性能可以关闭该功能。

RDB文件恢复

当Redis服务器启动时候，如果Redis 根目录存在 RDB 文件 dump.rdb，Redis 就会自动加载 RDB 文件恢复持久化数据。

验证RDB文件是否被加载

如果启动时候RDB文件加载了则会提示该消息
*DB loaded from dis:0.000 seconds

小提示:此外Redis服务器在加载期间会一直处于阻塞状态，直到工作完成为止。

RDB优缺点

RDB优点

• RDB的内容为二进制的数据，占用内存更小，更紧凑，更适合作为备份文件
• RDB进行数据恢复的速度很快，适合大规模的数据恢复。
• RDB采用写时复制技术进行持久化，这也使得在生成RDB文件时候，redis主进程不需要进行任何磁盘IO操作。

RDB劣势

• RDB数据丢失风险大
• RDB采用特定二进制格式保存且版本演进过程中有多个格式的RDB版本，存在老版本无法兼容新版本的问题
• RDB需要经常fork子进程进行保存数据集到硬盘，当数据集比较大时，fork的过程非常耗时，可能导致Redis在一些毫秒级不能响应客户端请求。