5-Redis 的持久化之 RDB
2016-12-22 13:58:48
该系列文章链接
NoSQL 数据库简介
Redis的安装及及一些杂项基础知识
Redis 的常用五大数据类型（key,string,hash,list,set,zset）
Redis 配置文件介绍
Redis 持久化之RDB
Redis 持久化之AOF
Redis 主从复制
Redis 事务
Redis 发布与订阅
Redis jdedis 介绍
redis 作为缓存的优秀数据库，也提供了将缓存中的数据写入到硬盘的手段。
有两种：一种是 RDB，另一种则是 AOF，本篇文章介绍 RDB。
1.RDB 简介
RDB：redis database
定义：在指定的时间间隔内将内存中的数据集快照写入到硬盘中，也就是 snapshot 快照，它恢复时是将快照文件直接读取到内存中
2.RDB 持久化过程
简单来说，就是 redis 会单独创建（fork）一个子进程来进行持久化，先将数据写入到硬盘中的一个临时文件中，等到持久化过程结束，就用这个临时文件替换上次持久化好的文件。
整个过程中，主进程不进行任何与之相关的IO操作，这就确保了 redis 的极高性能
那么：什么叫 fork？
redis 会复制一个与当前进程一样的进程。新进程的所有数据（eg:程序计数器）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
3.RDB 在 redis.conf 的配置
RDB 在 redis.conf 中的模块是 snapshotting。
下面简单介绍下 snapshotting
3.1 save
将数据库保存在磁盘上：
save <seconds> <changes>
如果同时发生了给定的秒数和针对DB的给定写入操作数，则将保存数据库。
在下面的示例中，出现这些情况将会保存：
在900秒（15分钟）内至少改变了1个 key
在300秒（5分钟）内至少改变了10个 key
在60秒内至少改变了10000个 key
注意：您可以通过注释掉所有"save"行来完全禁用保存。
也可以通过添加带有单个空字符串参数的save指令来删除所有先前配置的保存点，如下例所示：
save ""
3.2 stop-writes-on-bgsave-error
默认情况下，如果启用了RDB快照（至少一个保存点）并且最新的后台保存失败，Redis将停止接受写入命令。
这将使用户意识到（以一种困难的方式）数据没有正确地保存在磁盘上，否则很可能没有人会注意到以至于会发生一些灾难。
如果后台保存过程将再次开始工作，Redis将会自动允许再次写入。
然而，如果您已设置对Redis服务器和持久性的正确监视，则可能需要禁用此功能，以便即使磁盘，权限等存在问题，Redis也将继续正常工作。
3.3 rdbcompression
数据库在 dumb.rdb 文件保存数据时使用LZF压缩字符串对象？
默认设置为“yes”，因为它几乎总是一个胜利。
如果要在保存子项中保存一些CPU，请将其设置为“no”，但如果您具有可压缩值或键，则数据集可能会更大。
（在业界这个一般设置为 no,因为很多程序员认为不需要给老板省硬盘空间，毕竟在多买个硬盘就好了。空间换时间！）
3.4 rdbchecksum
RDB的第5版开始，CRC64校验和位于文件的末尾。
这使得格式更能抵抗损坏，但在保存和加载RDB文件时有一定的性能损失（大约10％），因此您可以禁用它以获得最佳性能。
禁用校验和创建的RDB文件的校验和为零，将告诉加载代码跳过检查。
3.5dbfilename
RDB方式保存数据的文件名
3.6 dir
工作目录。
数据将使用'dbfilename'配置指令指定的文件名写入此目录
aof 文件也将被创建在此目录中。
请注意，您必须在此处指定目录，而不是文件名。
4.如何触发或停止 RDB
触发 RDB 有很多种方式：
4.1 在 redis.conf -> save 中写下触发的条件
然后满足此条件会自动以 RDB 方式持久化
4.2 使用 save 或者 bgsave 命令主动触发快照
save: save 只管保存，其它所有读写操作都会阻塞
bgsave: redis 会在后台异步时进行快照操作，快照同时可以响应客户端请求，也可以通过 lastsave 命令获取最后一次成功执行快照的时间
4.3 执行 flushall 命令，这没有什么意义
动态停止 RDB 保存规则方法：
redis-cli config set save ""
5.反持久化：将 RDB 的数据还原到内存中
config get dir 获取存储数据的目录
将备份文件 dump.rdb 移动到 redis 安装目录并启动服务即可
6.RDB 的优势与劣势
6.1 优势
适合大规模的数据恢复
对数据完整性和一致性要求不高
6.2 劣势
在一定时间间隔内做一次备份，所以如果 redis 出现意外的话，就会丢失最后一次的所有修改
fork 父进程的时候，父进程内存中的数据被克隆了一份，大致 2 倍的膨胀率需要考虑
