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>
