redis学习十四：redis持久化之RDB

持久化技术：把内存中数据最终写入磁盘，RDB和AOF

为什么需要：防止服务器宕机缓存数据都没有了

 

 

 RDB：RDB持久性以指定的时间间隔执行数据集的时间点快照（实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为dump.rdb,其中，rdb就是redis database的缩写）

能干什么：能在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话说的snapshot内存快照，它恢复时再将硬盘快照文件直接读会内存里；

redis的数据都在内存中，保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，一锅端；

rdb保存的是dump.rdb文件

1.rdb配置：

这个是redis之前的配置，偷个懒直接用了尚硅谷的视频截图：

redis6.2以及7.0：

 这个就是dump.rdb保存路径，像我这个就是保存在当前目录

 2.rdb操作

（1）自动触发

可以通过config get命令获取密码，端口号等信息

 手动把配置文件设置成五秒修改两次则保存dump.rdb文件后去尝试可以看到确实保存了（每五秒检查一次，如果有两个修改则生成对应文件）：

 当我们写一个类似于flushdb/flushall时候redis会自动生成dump.rdb但是里面是空的，无意义

用shutdown时候也会生成，也莫得数据

 生成配置文件后，重新启动，就会按照你配置的路径去读取，最后就会恢复之前的数据

提醒：不可以把备份文件dump.rdb和生产redis服务器放在同一台机器，必须分开各自存储，以防生产机物理损坏后备份文件也挂了

 （2）手动触发

save：主程序执行会阻塞当前redis服务器，直到持久化工作完成，执行save期间，redis不能处理其他命令，线上禁止使用

bgsave：生产上都用这个，异步进行快照操作，不阻塞，快照同时还可以响应客户端的请求，该触发方式会fork一个子进程由子进程复制持久化过程

lastsave：获取最后一次成功执行快照时间，会得到时间戳，转换人性化可读一点可以这样：

fork：linux中，fork会产生一个和父进程完全相同的子进程，但子进程在此后会多exec系统调用，出于效率考虑，尽量避免膨胀

3.rdb优缺点

优点：适合大规模的数据恢复；按照业务定时备份；对数据完整性和一致性要求不高；RDB文件在内存中的加载速度要比AOF快得多。

缺点：在一定间隔时间做一次备份，如果redis意外down掉，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失；

内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能；

RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟fork的时候内存中的数据被克隆了一份，大致两倍的膨胀性；

4.rdb修复

像我的rdb没有损坏，所以是0个：

 5.rdb触发场景

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

手动执行save/bgsave命令；

执行flushall/flushdb命令也会产生dump.rdb，但里面是空的，无意义；

执行shutdown且没有设置开启AOF持久化；

主从复制时，主节点自动触发。

6.如何禁用快照

（1）redis-cli config set save ""

（2）在配置文件save ""

7.RDB配置详解

（1）默认yes，若bgsave错误，则马上停止写入，建议yes

 （2）是否压缩

 （3）是否使用CRC64算法来进行数据校验

 （4）在没有持久化情况下是否删除复制中使用的RDB文件，默认为no