05.Redis的RDB备份
说完了Redis避免数据丢失的方法一,AOF方法,其就好比是binlog,方便回滚
这一次,我们说另一种的持久化方式,内存快照.其就是在某一时刻将内存中的数据全部保存下来,就好比照片,在拍照的时候,在一瞬间将风景保留下来
Redis在某一时刻,将Redis的状态以文件的形式保存在磁盘上,成为快照,方便后续的数据恢复,全称为 Redis DataBase
和AOF相比,RDB记录的是某一个时刻的数据,并不是操作,所以,在数据恢复的时候,也可以直接将RDB读入内存,方便恢复
对于RDB的数据备份,我们将从多个方面进行讲解
首先是其一,那些数据进行快照
首先说,RDB主要是全量备份
对于全量备份,自然就是将内部所有的数据都记录在其中
然后是,RDB和主线程的关系
Redis提供了两种备份命令来实际备份
分别是save和bgsave
save在主线程中执行,会导致阻塞
bgsave 创建一个子进程,专门用于写入RDB文件,避免了主线程的阻塞,是Redis的默认配置
接下来,在深入一下,Redis在RDB的时候,其内部数据是否还可以修改吗
最完美的情况下,是不能进行修改,这样,我们备份的时候可以确保数据一致,但如果说,为了保证不能修改而阻塞主线程,那就有点得不偿失 ,假如内存有4G,那么一个全量备份时间阻塞主线程,时间有点没法接受
那么Redis为了解决这个问题,使用了操作系统的写时复制,就是bgsave子进程由主线程fork,可以共享主线程的所有内存数据,bgsave子进程运行之后,可以开始读取主线程的内存数据,并写入RDB文件
这时候如果主线程需要修改一块数据,那么这块数据就会被复制一份,生成这份数据的副本,主线程在这个数据副本上进行修改,bgsave就可以将原来的数据写入RDB文件
这就保证了快照的完整性的同事避免了主线程对数据进行修改
再来一说一个问题,快照的频率
即使采用了写时复制机制,但是还会有fork线程带来的必不可少的内存复制和fork过程的主线程阻塞
但如果我们引入了增量备份的机制,我们先在T0时刻做了一次快照,那么接下来一段时间,我们只需要记录哪些数据被修改了就行
但是对每个键值对,都记录其修改,那么就和AOF的工作有些冲突了
所以Reids只提供了对应的全局快照机制
对于数据的备份,Reids自从4.0之后,提出了混合使用AOF日志和快照的方法
这样快照不必很频繁的执行,AOF也保证了短期的增量操作备份,避免了重写开销
那么总结一下这次学习所得
Redis为了避免数据丢失,增加了数据全量快照RDB,但是其也是有一点的缺点,因为是一个内存的大合照,所以更加耗时耗力,故频繁快照不太能接受,Redis也是建议混合使用两者,取两者之长,避两者之短
最后提出一个疑问
如果是一个Reids在主机上做持久化保证,读写比例在2:8左右,大部分都是写请求,在此过程中,RDB有何风险?
说一个简单的问题,在fork结束之后,因为懒加载,所以只有写的时候才会重新开辟物理内存,而8:2的比例代表着写的几率太大了,所以必然会占用内存空间,很有可能会把物理内存占满