Redis系统学习（高级篇）-Redis持久化-RDB方式

目录

一、RDB是什么？

二、RDB的执行时机

三、RDB的其他命令

四、RDB的执行原理

五、RDB的优缺点

---

一、RDB是什么？

RDB全称叫Redis Database Backup file（Redis数据备份文件） ，也叫Redis数据快照，就是将数据快照保存在磁盘中，下次再从磁盘中恢复到内存中。这个RDB文件默认存在运行目录

二、RDB的执行时机

有四个：

1. Redis停机的时候

会自动执行save命令，完成RDB持久化

但这种方式并不是没有问题的，如果遇到一个很极端的情况，可能还没有生成数据快照，那么就可能造成数据丢失。因此建议手动执行save命令

2. 执行save命令

这个就能执行RDB，但是这个是由主进程来执行RDB的，因此现在主进程就干不了其他事了，就阻塞住了，就不能再去处理其他请求了，效率不高。所以就有了bgsave命令的出现，这个可以开一个子进程异步的执行，提高了效率

3. 执行bgsave命令

这个的话就是开了一个子进程来单独的异步执行RDB操作。提高了效率

4. 触发RDB条件时

可以在redis.conf文件中配置触发条件。

触发条件就是在一段多长的时间内，至少对多少个key执行了修改操作就自动执行RDB

使用：

save  时间  key个数

如果是 save "" 则代表禁用掉RDB

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000 

三、RDB的其他命令

可以设置是否压缩、RDB文件名、RDB的存放位置

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./ 

四、RDB的执行原理

当执行bgsave命令的时候

会fork一个子进程

其实Redis是不能直接的操作物理内存的，但是在Redis中有一个虚拟内存，虚拟内存可以通过页表来映射物理内存，fork过去关键就是将页表复制过去了，所以子进程也能够映射到主进程映射的那个物理内存数据，因此就实现了子进程和主进程保持相同的数据。这样就可以不需要直接拷贝物理内存也能达到备份的效果，提高效率，然后子进程映射到那个物理内存的数据之后将其写到新的RDB文件中，最后将老的RDB文件进行替换

但是这里需要注意的是这里物理内存中的数据是只能读的，不能够直接写的，因为如果又读又写（修改）势必存在并发问题，就可能还没来得及读到写的数据，造成读到的不是最新的数据，读到的是脏数据。所以现在就在物理内存中又复制了一个副本，对这个副本进行修改，然后再将主进程的虚拟内存映射了这个副本，就确保读到的是最新的数据，随后也能保证子进程也能映射到这个最新的数据

这个如果说子进程还没读完了，现在主进程在疯狂对数据进行修改的话，对每个数据都进行修改，那么就会都产生一个副本，会很造成物理内存的占用 

注意：虽然说这种方式异步的产生一个子进程的方式已经很大程度上让主进程不阻塞了，但并不是完全不阻塞的，在fork的时候其实是主进程只能干这件事的，不能再处理其他请求了。也就是其实是主进程相较于原来save的方式就不要再处理这个写RDB文件的过程了，只需要阻塞这个fork的过程

五、RDB的优缺点

优点：

1. 恢复速度快

2. 产生的文件不是很大

缺点：

1. 因为这个触发RDB是存在这个时间间隔的，不能将这个时间间隔搞得太小，这个很影响性能，Redis根本忙不过来 所以就需要搞得相对来说长一点 长一点的话  比如说60s 如果说这60s的间隔内恰好Redis宕机了，就会导致上一次提交到目前所有的操作就全不见了，导致数据丢失

这个归根结底是因为Redis这种处理RDB能力有限的原因，之后会有AOF的方式，这种是每次都记录写操作命令，因此能很大程度的保留操作，所以AOF方式就能很好的保证数据的完整性

2. fork子进程、写出RDB文件、压缩这些操作都是挺耗CPU时间的

因此其实RDB对资源的占用并不小，

内存资源就是那个fork过程中的产生副本的时候

CPU资源就是压缩，写出RDB文件时候