RDB · JAVA · 看云

[TOC] # 简介在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是快照，它恢复时是将快照文件直接读到内存里，Redis会单独创建（fork）一个子进程来进行持久化。一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。 **RDB的缺点是最后一次持久化后的数据可能丢失。** 备注解释： --fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程 # 如何触发RDB快照配置文件中默认的快照配置 ~~~ save 900 1 #刷新快照到硬盘中，必须满足两者要求才会触发，即900秒之后至少1个关键字发生变化。 save 300 10 #必须是300秒之后至少10个关键字发生变化。 save 60 10000 #必须是60秒之后至少10000个关键字发生变化。（以上3个选项都屏蔽，则rdb禁用） ~~~ ~~~ stop-writes-on-bgsave-error yes #后台存储错误停止写。 rdbcompression yes #使用LZF压缩rdb文件。 rdbchecksum yes #存储和加载rdb文件时校验。 dbfilename dump.rdb #设置rdb文件名。 dir ./ #设置工作目录，rdb文件会写入该目录。 ~~~ **命令save或者是bgsave** * save：save时只管保存，其它不管，全部阻塞 * bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。非阻塞,内存会增加.可以通过lastsave命令获取最后一次成功执行快照的时间执行redis的bgsave命令时，redis会fork一个进程把redis中的内存数据写入磁盘。这样的好处是，copy on write，有效的节省了内存占用。但是，bgsave时，如果有数据变更，一样需要申请内存注：执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义默认RDB方式保存的是dump.rdb文件，恢复也是识别的是dump.rdb # 配置位置,快照恢复查看目录 CONFIG GET dir获取目录 **将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可或者就在当前目录启动** 举例：我的redis启动服务的目录是 /usr/local/bin 下面我启动redis的目录是/root 下面，然后生成的的dump.rdb 文件也是在/root 目录下，假如redis服务器出现问题，挂掉了。那么想要根据rdb恢复数据（1）将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务（2）当前目录启动如果我的dump.rdb 在/root下面，而我到/usr/local/bin这个目录下去启动了redis，那么数据是无法恢复的。只能从 /root 下面启动才能看到之前保存的数据。如下操作： ~~~ 127.0.0.1:6379> CONFIG GET dir #获取当前操作的目录 1) "dir" 2) "/root" 127.0.0.1:6379> KEYS * #redis中存在的key 1) "myhash" 2) "k3" 3) "mylist" 4) "b1" 5) "du1" 6) "k1" 7) "b4" 8) "key1" 9) "d" 10) "myset" 11) "du11" 12) "list" 13) "b3" 14) "du" 15) "b2" 16) "skey" 17) "k2" ~~~ 下面我关闭redis，假设redis服务挂掉！ ~~~ 127.0.0.1:6379> SHUTDOWN #关闭服务器 [root@localhost ~]# pwd #当前目录是/root /root [root@localhost ~]# ll #下面有dump.rdb这个文件总用量 52 -rw-------. 1 root root 1208 6月 14 08:10 anaconda-ks.cfg drwxr-xr-x. 3 root root 4096 6月 17 04:35 dufy -rw-r--r--. 1 root root 283 6月 19 00:13 dump.rdb -rw-r--r--. 1 root root 24772 6月 14 08:10 install.log -rw-r--r--. 1 root root 7690 6月 14 08:09 install.log.syslog ~~~ 那么当我进入/usr/local/bin 目录下启动重新启动redis，看数据是否恢复 ~~~ [root@localhost ~]# cd /usr/local/bin/ [root@localhost bin]# pwd /usr/local/bin [root@localhost bin]# redis-server /root/dufy/redis/redis-3.0.4/redis.conf [root@localhost bin]# redis-cli 127.0.0.1:6379> KEYS * # 这里启动后，查看key没有恢复 (empty list or set) 127.0.0.1:6379> ~~~ 那么我再次关闭服务，从/root下启动redis看数据是否恢复 ~~~ 127.0.0.1:6379> SHUTDOWN not connected> exit [root@localhost bin]# cd /root/ [root@localhost ~]# pwd /root [root@localhost ~]# redis-server /root/dufy/redis/redis-3.0.4/redis.conf [root@localhost ~]# redis-cli 127.0.0.1:6379> KEYS * #重启后，查看key，发现恢复成功了！ 1) "k1" 2) "b1" 3) "key1" 4) "list" 5) "du11" 6) "du1" 7) "b4" 8) "k3" 9) "myhash" 10) "b3" 11) "d" 12) "skey" 13) "mylist" 14) "du" 15) "k2" 16) "b2" 17) "myset" 127.0.0.1:6379> ~~~ 上面说的这一句：将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可或者就在当前目录启动。 # 如何停止RDB 配置文件注释掉 ~~~ save 900 1 save 300 10 save 60 10000 ~~~ 启动 # save ""，去掉 #。保存后重启动态停止RDB命令在redis-cli中执行： ~~~ config set save "" ~~~ # 总结 ~~~ 内存中的数据对象 --->rdbsave --> 磁盘中的rdb文件内存中的数据对象 <---rdload <-- 磁盘中的rdb文件 ~~~ * RDB是一个非常紧凑的文件 * RDB在保存RDB文件时父进程唯一需要做的就是foker出一个子进程，接下来工作全部交给子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能 * 与AOF相比，在恢复大的数据时候，RDB方式更快一些 * 数据丢失风险大 * RDB需要经常folk子进程来保存数据集到磁盘，当数据集比较大额时候，folk的过程是比较耗时的，可能会导致redis在一些毫秒级不能响应客服端请