Redis学习——Redis持久化之RDB备份方式保存数据

从这一个介绍里面知道，redis比memcache作为缓存数据库强大的地方，一个是支持的数据类型比较多，另一个就是redis持久化功能。

下面就介绍Redis的持久化之RDB！

一：什么是redis的持久化

官网介绍：

英文：https://redis.io/topics/persistence

中文：http://www.redis.cn/topics/persistence.html

二：Redis的RDB是什么？

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里，Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到。

一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

备注解释：

--fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

--AOF方式，点击这里查看[待补充]！

三：Redis配置文件redis.conf中关于RDB的相关配置

首先贴出来配置信息：

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

# The filename where to dump the DB
dbfilename dump.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

如果上面的配置文件有看不懂，请点击这里进行想关的查看了解：Redis配置文件-redis.conf详解

1：如何触发RDB快照

• 配置文件中默认的快照配置

save 900 1
save 300 10
save 60 10000

• 命令save或者是bgsave
  
  SAVE：save时只管保存，其它不管，全部阻塞
  
  BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave
  
  命令获取最后一次成功执行快照的时间

注：执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

2:默认RDB方式保存的是dump.rdb文件，恢复也是识别的是dump.rdb

3:配置位置，以及快照恢复

查看目录

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"
127.0.0.1:6379>

下面我关闭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 安装目录并启动服务即可或者就在当前目录启动。

四：Redis优点

• 适合大规模的数据恢复

• 对数据完整性和一致性要求不高

五：Redis缺点

• 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
• fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

六：如何停止RDB

1: 配置文件注释掉

	save 900 1
	save 300 10
	save 60 10000

启动 # save ""， 去掉 #。保存后重启

2:动态停止RDB命令

在redis-cli中执行：

config set save ""

七：大总结

		内存中的数据对象 --->rdbsave --> 磁盘中的rdb文件
		内存中的数据对象 <---rdload <-- 磁盘中的rdb文件

• RDB是一个非常紧凑的文件
• RDB在保存RDB文件时父进程唯一需要做的就是folk出一个子进程，接下来工作全部交给子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能
• 与AOF相比，在恢复大的数据时候，RDB方式更快一些
• 数据丢失风险大
• RDB需要经常folk子进程来保存数据集到磁盘，当数据集比较大额时候，folk的过程是比较耗时的，可能会导致redis在一些毫秒级不能响应客服端请求

---

欢迎访问我的csdn博客，我们一同成长！

"不管做什么，只要坚持下去就会看到不一样！在路上，不卑不亢!"

博客首页：http://blog.csdn.net/u010648555