289-Redis（Redis持久化-RDB方式）

1、持久化简介

什么是持久化？

• 利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

为什么要进行持久化？

• 防止数据的意外丢失，确保数据安全性

保存的方式:

• ​RDB(快照)： 定时将数据持久化到硬盘中
• AOP(日志)： 保存操作的过程

2、RDB

2.1、RDB启动方式

2.1.1、RDB启动方式 —— save指令

命令：

save	#每执行一次就会保存一次数据

作用： 手动执行一次保存操作

2.1.2、RDB启动方式 ——dump.rdb文件

save之后，会在data中生成dump.rdb文件


这个rdb文件就是持久化文件！

将这个文件删掉，客户端再save一下！


又生成了dump文件！

加点内容：

再save一下，比较一下，此时两个文件大小已经发生变化了

2.1.3、RDB启动方式 —— save指令相关配置

将服务关闭重启：

插入一个键值对，然后save!


查看内容：

再添加一个键值对，然后save:

OK的！

数据恢复演示：

先关掉服务：

重新启动：

打开客户端查看数据：

可以看到此时的数据还在！是在redis启动的时候，将数据加载了！

2.1.4、RDB启动方式 —— save指令工作原理

• redis是单线程的！
• 注意： save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。
  
  #### 数据量过大，单线程执行方式造成效率过低如何处理？
  后台执行！
  

2.1.5、RDB启动方式 —— bgsave指令

命令：

bgsave	#后台保存

作用： 手动启动后台保存操作，但不是立即执行

可以看到提示，表示在后台执行的！

可以看到，和上次相比，文件的大小已经变了：


工作原理：

是不是上面这个过程，我们可以查看日志文件：


确实是在后台启动了一个进程进行操作的！

---

注意：

• bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。
• save是马上执行，加入到任务执行的工作队列中！
• bgsave是后台创建一个子进程来完成的！

2.1.6、RDB启动方式 —— bgsave指令相关配置

反复执行保存指令，忘记了怎么办？不知道数据产生了多少变化，何时保存？

2.1.7、RDB启动方式 ——save配置

配置：

save second changes		#后台用的是bgsave指令

作用： 满足限定时间范围内key的变化数量达到指定数量即进行持久化。

参数：

• second：监控时间范围
• changes：监控key的变化量

位置： 在conf文件中进行配置。

再次启动服务端：



可以看到只改变一个key，没有rdb文件：

在里面再插入一个key，就会发现：


再次插入键值对，只有第2次插入时，rdb文件才会写入，文件大小有变化：

执行get指令：

rdb文件内容不会发生变化：（只有key发生变化，才会修改rdb文件的内容）

del也是，只有操作两次，才会有变化！



注意：

• save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
• save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
• save配置启动后执行的是bgsave操作

2.1.8、RDB三种启动方式对比

2.1.9、RDB的优点和缺点