redis的持久化：RDB的配置

RDB 详解

RDB持久化方式是指在指定时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中,Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，等到持久化过程结束，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次的数据可能会丢失

从配置文件了解RDB

打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容
1 RDB核心规则配置（重点）

save 900 1
save 300 10
save 60 10000

那么只要满足以下三个条件中的任意一个，BGSAVE命令就会被执行
服务器在900秒之内，对数据库进行了至少1次修改
服务器在300秒之内，对数据库进行了至少10次修改　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

服务器在60秒之内，对数据库进行了至少10000次修改。

2 指定本地数据库文件名，一般采用默认的 dump.rdb

3 指定本地数据库存放目录，一般也用默认配置

4 默认开启数据压缩

################################ 快照  #################################  
#  
# 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  
  
# 工作目录  
#  
# 导出的数据库会被写入这个目录，文件名就是上面'dbfilename'配置项指定的文件名。  
#   
# 只增的文件也会在这个目录创建（这句话没看明白）  
#   
# 注意你一定要在这个配置一个工作目录，而不是文件名称。  
dir ./  

手动执行RDB备份

save:

127.0.0.1:6379> set user n1
OK
127.0.0.1:6379> save
OK

127.0.0.1:6379>

bgsave:

[root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-cli
127.0.0.1:6379> save
OK
127.0.0.1:6379> set addr bj
OK
127.0.0.1:6379> BGSAVE
Background saving started

 

注意： bgsave命令是针对save阻塞问题做的优化。 Redis内部所有涉及到RDB操作都采用bgsave的方式， save命令可以放弃使用。

触发RDB快照

1 在指定的时间间隔内，执行指定次数的写操作
2 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令
3 执行flushall 命令，清空数据库所有数据，意义不大。
4 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义...也不大。

通过RDB文件恢复数据

将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。可以从下面的操作演示中可以体会到。

RDB 的优缺点

优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：
1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

操作演示

[root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-server redis.conf
[root@iZbp143t3oxhfc3ar7jey0Z redis-4.0.12]# redis-cli
127.0.0.1:6379> save
OK
127.0.0.1:6379> set addr bj
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379> set n1 12
OK
127.0.0.1:6379> set n1 13
OK
127.0.0.1:6379> set n1 15
OK
127.0.0.1:6379> set n2 12
OK
127.0.0.1:6379> set n3 123
OK
127.0.0.1:6379> set 11 ser
OK
127.0.0.1:6379> set 124 werew
OK
127.0.0.1:6379> set we re
OK
127.0.0.1:6379> set 131 eq
OK
127.0.0.1:6379> set 12  sf
OK
127.0.0.1:6379> set rr rr
OK
127.0.0.1:6379> set aa  aa
OK
127.0.0.1:6379> set pp pp
OK
127.0.0.1:6379> set asd pp
OK
127.0.0.1:6379> set ss pp
OK
127.0.0.1:6379>