Redis中RDB操作_redis rdb流程

概念

• RDB=RedisDateBase,Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一但服务器进程退出，服务器中的数据库状态也会消失。所以需要用到持久化功能！
• RDB持久化是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化)，保存的文件后缀是rdb；当Redis重新启动时，可以读取快照文件恢复数据。
• RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
• 一般Redis默认启动RDB

具体原理

Redis单独创建（fork）一个子进程进行持久化，会先将数据写入到一个临时的文件中，待持久化过程都结束了，在用这个临时文件替换上次持久化好的文件。整个过程中，主进程食不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，拿RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能会丢失。

RDB配置详解：

在配置文件redis.conf全局搜索SNAPSHOTTING

RDB配置

1.通过搜索SNAPSHOTTING找到配置，并且配置触发条件

那么只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行
服务器在900秒之内，对数据库进行了至少1次修改
服务器在300秒之内，对数据库进行了至少10次修改　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
服务器在60秒之内，对数据库进行了至少10000次修改。
我这里配置了60秒之内，对数据库进行了至少5次修改就触发RDB。其他的被我注掉了。

2.开启保存出错停止写入功能（默认开启）

如果RDB快照持久化操作被激活（至少一个条件被激活）并且持久化操作失败，Redis则会停止接受更新操作。

3.数据压缩（默认开启）

4.RDB文件校验（默认开启）

这会让格式更加耐攻击，但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降

5. 指定本地数据库文件名，一般采用默认的 dump.rdb
   
   6.rdb文件是否删除同步锁（默认不开启）。
   
6. 生成文件的工作目录
   
   
   

################################ 快照  #################################  
# Save the DB on disk:保存数据库到磁盘  
#   save <秒> <更新>   
#   如果指定的秒数和数据库写操作次数都满足了就将数据库保存。  
#   下面是保存操作的实例：  
#   900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）  
#   300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）  
#   60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）    
#   注释：注释掉“save”这一行配置项就可以让保存数据库功能失效。   
#   你也可以通过增加一个只有一个空字符串的配置项（如下面的实例）来去掉前面的“save”配置。  
#   save ""  
  
save 900 1  
save 300 10  
save 60 10000  
  
#在默认情况下，如果RDB快照持久化操作被激活（至少一个条件被激活）并且持久化操作失败，Redis则会停止接受更新操作。  
#这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题，可能会造成灾难。  
#如果后台存储（持久化）操作进程再次工作，Redis会自动允许更新操作。  
#然而，如果你已经恰当的配置了对Redis服务器的监视和备份，你也许想关掉这项功能。  
#如此一来即使后台保存操作出错,redis也仍然可以继续像平常一样工作。  
stop-writes-on-bgsave-error yes  
  
#是否在导出.rdb数据库文件的时候采用LZF压缩字符串和对象？  
#默认情况下总是设置成‘yes’， 他看起来是一把双刃剑。  
#如果你想在存储的子进程中节省一些CPU就设置成'no'，  
#但是这样如果你的kye/value是可压缩的，你的到处数据接就会很大。  
rdbcompression yes  
  
#从版本RDB版本5开始，一个CRC64的校验就被放在了文件末尾。  
#这会让格式更加耐攻击，但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降，  
#所以，为了达到性能的最大化，你可以关掉这个配置项。   
#没有校验的RDB文件会有一个0校验位，来告诉加载代码跳过校验检查。  
rdbchecksum yes  
  
# 导出数据库的文件名称  
dbfilename dump.rdb  

#rdb文件是否删除同步锁
rdb-del-sync-files no
  
# 工作目录  
# 导出的数据库会被写入这个目录，文件名就是上面'dbfilename'配置项指定的文件名。   
# 新增的文件也会在这个目录创建    
# 注意你一定要在这个配置一个工作目录，而不是文件名称。  
dir ./  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

测试RDB机制：

1.登录客户端查看RDB文件生成目录

config get dir
1

2.删除原来的RDB文件

rm -rf dump.rdb 
1

3.登录客户端，设置五个值

4.查看生成目录（60秒内新增5个key，所以生成了dump.rdb文件）

5.结束redis的进程（如果没有RDB，数据应该会丢失）

确认进程已经结束

ps -ef|grep redis
1

6.重新开启redis服务

./bin/redis-server ./redis.conf
1

7.重新启动客户端，获取k1的值，发现可以获取到，证明持久化起到作用了。

8.再测试下，直接清空数据库，看是否也会触发持久化

在客户端执行flushall

发现也生成了rdb文件

总结：

1.save规制满足情况下，会自动触发rdb规则，生成文件
2.执行flushall命令，也会触发rdb规则，生成文件
3.退出redis，也会触发rdb规则，生成文件
4.重启redis的时候，会自动读取dir目录下的rdb文件，自行恢复数据

优点：
1、适合大规模数据恢复
2、对数据完整性要求不高
缺点：
1、需要一定时间间隔进行操作,如果redis意外宕机了，最后一次修改数据就没有了！
2、备份时占用内存，因为Redis 在备份时会独立创建一个fork进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。