Redis高级篇: Redis的持久化机制

善良小茅

已于 2022-10-22 10:34:45 修改

阅读量163

点赞数

分类专栏： redis 文章标签： redis 数据库缓存

于 2022-10-22 10:33:52 首次发布

本文链接：https://blog.csdn.net/qq_55388189/article/details/127445550

版权

redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

学习目标

了解redis的持久化机制有哪些? RDB和AOF
了解RDB持久化的方案
了解AOF持久化的方案
了解RDB和AOF持久化的优劣
了解RDB和AOF持久化的配置和手动实验
最佳实践: Redis持久化选择RDB还是AOF? 同时存在数据恢复优先选择那个?AOF优先级更高
相关知识: Redis集群/主从模式下持久化的流程和实现原理

总结:

Redis持久化解决的是Redis数据安全性的问题

在这里插入图片描述

RDB`Redis Database Backup file默认开启`

Redis数据备份文件,也被叫做Redis数据快照
简而言之:定期将所有数据写入磁盘持久化保存,但是在持久化的过程中容易丢失部分数据,可以结合AOF弥补

解读:	
什么是RDB?
就是定时把内存中存储的所有数据刷到磁盘持久化保存,当Redis故障/重启,从磁盘中读取快照RDB后,重新写入内存恢复数据

保存位置?
默认保存在当前运行目录 ./

RDB的时间选择?
1. 不能太长,可能出现数据丢失
2. 不能太短,磁盘读写过多

注意点:
每次RDB都会将所有数据重新写入磁盘

rdb相关配置命令

save命令不建议使用: 手动触发RDB备份操作,由redis主进程完成,会导致主进程阻塞
bgsave命令建议使用: 开启子进程完成RDB操作,避免主进程受到影响,但是中间会出现数据误差
redis停机是会自动进行RDB操作

配置redis.conf,实现定时rdb


# 900s内,如果至少有一个key被修改,则执行bgsave,如果是save " "标识禁用RDB
save 900 1 
save 300 10 
save 60 10000

# 其他配置
dbfilename dump.rdb # rdb文件名称
# 文件保存的路径
dir ./
# 是否压缩rdb,不建议开启,压缩会消耗CPU资源,磁盘容量不值钱
rdbcompression yes

RDB的fork原理

bgsave开始时会fork主进程得到子进程fork的过程.主进程阻塞,子进程共享主进程的内存数据,完成fork后读取内存数据写入到RDB文件

在这里插入图片描述

解读:

前置知识: 
1. 在linux操作系统中,所有的进程,都无法直接操作物理内存,而是由操作系统为每个进程分配一段虚拟内存,然后操作系统会维护一个虚拟内存和物理内存之间的映射关系表,这个表叫做页表,所有主进程操作虚拟内存,而虚拟内存基于页表的映射关系去读写数据到物理内存,这样就能够实现对物理内存的读写了

RDB fork流程分析:
垃圾方案: 将主进程页表对应的所有物理数据全部复制一份,得到新的页表`严重浪费存储空间`

最佳方案: 
1. 创建一个子进程,拷贝主进程的页表到子进程
2. 子进程在操作虚拟内存的时候,跟主进程的映射关系一样,最后肯定能操作到和主进程相同的物理内存区域,这样就实现了子进程和主进程内存空间的共享,就不需要拷贝内存数据实现数据共享,大大缩短拷贝时间
3. 然后写入到rdb文件中,替换旧的rdb文件

脏数据问题:
4. 在子进程读取虚拟内存-->物理内存,拷贝数据的期间,主进程可能对虚拟内存进行写操作,主进程和子进程可能出现读写冲突导致脏数据
5. 所以为了避免这个问题发生,fork底层采用copy-on-write技术,标记共享的物理内存和read-only,主进程想要写数据就拷贝一份,然后更新主进程的页表

注意点:
最坏情况下,可能对所有备份的数据全部进行了修改,物理内存上的数据存储量就会翻倍,所以我们最好给redis机器预留一大半的内存空间

6. 子进程只拷贝主进程的页表,主进程和子进程共享物理内存上的数据,数据只保存一份,两个进程共享
7. 进程共享数据,进行备份的时候,如果出现写操作,容易出现脏数据,所以设置共享的物理内存为只读,如果主进程在备份期间进行了写操作,就拷贝数据副本,然后修改主进程的页表对应的映射关系

RDB的缺点

RDB的执行间隔时间较长,容易导致数据丢失
RDB持久化的时候fork子进程以及一次性全量写出数据到磁盘比较耗时

AOF`Append Only File追加文件`

Redis处理的每一个命令都会记录在AOF文件中,可以看做命令日志文件
简而言之:将Redis的所有写操作命令都记录到AOF文件中

在这里插入图片描述

AOF相关配置命令

在这里插入图片描述

解读: CAP保证高可用还是高可靠/折中方案
1. appendfsync always: 每次执行写操作命令,先完成写内存操作,再写命令到磁盘,一气呵成,跟数据库操作累死,绝对的数据安全,但是执行效率低
2. appendfsync everysec: 缓冲区暂存指令,定时写磁盘,但是1s内宕机就会丢失数据,`最多丢失1s内的命令,允许`
3. appendfsync no: 性能最好,安全性最低

在这里插入图片描述

AOF文件重写
在这里插入图片描述

RDB和AOF优缺点对比

在这里插入图片描述

解读
RDB是定义对内存的数据备份到文件|AOF记录每次写命令到文件,所以AOF的效率天然比RDB高;
但是AOF记录每一条命令,会存在大量重复指令,而RDB完整备份数据,所以RDB文件比AOF体积更小;
因为RDB是定期更新,而AOF是记录每一条写指令,所以AOF的数据安全性更高;
因为RDB记录完整数据,恢复数据直接写入即可,而AOF是让redis重新执行大量指令,效率低;
RDB文件最坏情况会出现双倍内存占用,并且压缩需要CPU资源,而AOF仅仅是命令的IO操作,所以系统占用比RDB低

场景:
如果追求极致的数据安全: 使用AOF
如果能够容忍部分数据安全: 使用RDB更好