Redis持久化之RDB

目录

RDB方式启动：

方式1：使用save命令 ->手动执行一次保存操作

save指令相关配置：

方式二：使用bgsave命令 ->手动执行存储数据，但不是立即执行

bgsave命令的相关配置，以save指令的相关配置为基础：

方式三：自动执行

save配置

 save和bgsave的对比：

RDB的优点：

RDB的缺点:

---

什么是持久化：持久化就是将用户写入缓存中的数据存入到硬盘中，用于数据的恢复

为什么要持久化：避免未保存之前断电或者系统崩溃导致数据的丢失，便于数据的恢复

Redis持久化保存的是什么：

①以RDB方式进行持久化，将当前的数据状态进行保存，以快照的方式，存储数据结果

②以AOF方式进行持久化，将数据的操作过程进行保存，以日志文件的方式，存储操作过程

RDB方式启动：

方式1：使用save命令 ->手动执行一次保存操作

用户在任何时间都可以保存数据

save指令相关配置：

①dbfilename

说明：设置本地数据库文件名，默认为dump.rdb

经验：通常设置为dump-端口号.rdb

②dir

说明：设置.rdb文件的路径

经验：通常设置成存储空间较大的目录中，目录名为data

③rdbcompression yes

说明：设置存储到本地数据库时是否压缩数据，默认为yes，采用LZF压缩

经验：通常默认为开启状态，如果设置为no，可以节省cpu的运行时间，但会使存储文件变得很庞大

④rdbchecksum yes

说明：设置是否进行RDB文件格式的校验，该校验过程在写文件和读文件过程均进行

经验：默认设置为开启，如果设置为no，虽然节省了读写的时间但是可能会造成数据的损坏

 

 可以看出我们写的数据被保存了

接下来，我们就说说save的执行流程：

由于Redis服务器是单线程执行任务，如果说save前面的指令非常的多则执行到save时服务器会执行时间非常长，后面的任务就会阻塞，这是不可以忍受的。 

方式二：使用bgsave命令 ->手动执行存储数据，但不是立即执行

用户发起指令，redis服务器控制指令的执行，即时发起，合理时间执行，存储数据

bgsave命令的相关配置，以save指令的相关配置为基础：

stop-writes-on-bgsave-error yes

说明：后台存储过程中出现错误，是否停止保存

经验：通常默认开启

从图片可以看出，执行bgsave命令之后控制台会打印一句后台保存开始，也可以在日志文件中看到最后一句后台保存成功结束，由此可以看出bgsave是异步执行的。

接下来，我们说说bgsave的执行流程：

说明： bgsave命令是针对save阻塞进行的优化，redis中所涉及到rdb操作都是采用bgsave的方式，save命令基本上可以放弃使用了

虽然bgsave命令解决了save命令阻塞的情况，但是需要用户手动输入指令，人都是健忘的很有可能忘记，因此推荐使用方式三。

方式三：自动执行

服务器发起指令，满足条件，存储数据

save配置

·配置

save second  changes

·作用

     满足规定时间范围内key的变化数量达到指定数量即可进行持久化

·参数

      second：监控时间范围

      changes：监控key的变化量

·位置

        在conf文件中配置

·默认配置

save 900 1
save 300 10
save 60 1000

 save和bgsave的对比：

指令	save	bgsave
读写	同步	异步
是否阻塞客户端指令	是	否
是否消耗额外的内存	否	是
是否开启新的进程	否	是

 

 

rdb特殊启动形式： 

①全量复制(在主从复制中会说到）

②服务器运行过程中重启->debug reload

③关闭服务时指定保存数据->shutdown save  默认执行shutdown指令时自动执行bgsave(如果没有开启AOF持久化功能)

RDB的优点：

①RDB是一个紧凑的二进制文件，存储效率非常高

②RDB存储的是某个时间点的数据快照，非常适合用于数据备份、灾难性恢复

③RDB恢复数据的速度要比AOF快得多

RDB的缺点:

①RDB无论执行指令还是设置配置，都无法满足实时持久化，具有较大的可能丢失数据

②bgsave指令每次执行都要调用fork函数生成子进程执行持久化，要牺牲掉一些性能

③rdb在redis版本中还并不兼容