Redis底层原理-持久化【详细易懂】

Redis底层原理-持久化

好久没更文了,最近开始重拾自己技术博文,并整理沉淀下自己的技术,

因为之前感觉都是你一说,我感觉会,但是真叫我说,我_{又说不出来}

_哈哈哈!尴尬的场面(别问了,本人亲身体验过)

不废话了,一起吸收一波吧!

主要支持的两种持久化机制: RDB和AOF

RDB

RDB文件的生成是否会阻塞主线程?分情况

save:阻塞主线程

bgsave:创建子进程(专门写入RDB文件) 也是自动保存(配置文件中)的命令

但是手动确很不方便,怎么自动进行配置?—>

1.配置文件中:save命令操作

我们在Redis安装目录中的redis.windows-service.conf(里面用的就是bgsave)

2.自动机制: shutdown

从节点执行全量复制操作,主节点自动执行bgsave生成一个RDB文件发给从节点,

3.使用sqve "":关闭持久化,就是一个纯内存的的缓存软件

思考:bgsave问什么可以不阻塞?(面试题)

我们看下方此图

答案:

• 避免不阻塞采用一个技术: 写时复制机制
• 首先主线程在运行时,会花费一个t1主线程->子进程的时间去fork一个子线程(fork的过程会阻塞)
• 接下来: 对于主线程是读取的操作,则没有任何影响,主线程正常到内存读取(然后到子进程保存)
• 但是:若是修改的操作,如下图所示,主线程修改键值对B,Redis的会在内存中启动写时复制来保存主线程的当前修改操作的键值对B值
• 最后将主线程的读或者写的操作交给子进程写成快照保存

RDB保存的快照文件默认采用LZF压缩算法来保存,在配置文件中(默认开启)

rdbcompression yes

如果检验快照文件是否损坏?怎么检查

找到你安装的Redis目录,打开cmd黑窗口,输入如下命令

思考:快照时数据能修改吗?

当然能!!为什么?

答案:

• 我们每次的保存,正如上面的配置文件中保存bgsave命令,都会修改快照文件数据,所以能修改
• 但是会存在一个问题,如下图所示,会存在数据的丢失问题,这RDB弊端怎么解决呢?

接下来,我们就需要引入AOF了

AOF(Append Only File)

开启的命令:

appendonly yes

思考:AOF的持久化原理是什么?

结合下图理解

• 首先lpush操作命令写入

• 然后第1步采用append的AOF缓冲区进行写入,采用RESP协议(文本协议)我们看下图可以看到AOF缓冲区里面的一堆字符

• 第2步:我们会看到appendfsync:表是缓冲区向磁盘写(三个参数)表示写入的时间,当中的everysec:每隔一秒进行保存,no:没有间隔(追求高性能)

• 第3步:rewrite重写机制,将AOF的缓冲区的文件通过rewrite进行AOF的重写缓冲,减少文件的大小(重写目的为了避免重复)

• 注意:我们看下图,命令写入的时候(在重写的过程中都可),00-后续的命令写入,也会进行AOF重写缓冲(就是不是首次的命令)

• 最后:当Redis进行重启的时候,Redis就会拿着AOF文件进行对照着恢复了

AOF 持久化的整个流程图

思考:Redis重启时如何启动的呢?流程是什么?

• 1.首先查看是否开启AOF,
• 2.是的话,进行检测有没有AOF文件有就进行加载,没有就加载RDB文件
• 3.否的话:检测有没有RDB文件,有则进行加载RDB文件,没有就正常启动(啥都不加载)
• 4.判断启动是否成功: 是就成功,否就失败
• 总之:优先加载AOF,再看RDB

通过上面的阅读,我们也了解了AOF对性能要求高,RDG又存在数据丢失的问题,都不完美(要做全量),怎么办呢?有没有中间方案?

答案:有的(哈哈哈!~)我们继续往下看

RDB-AOF混合持久化

开启命令:

aof-use-rdb-preamble yes

全流程图

我们可以看到rewrite的过程中下方的AOF文件,首先加载RDB文件

混合模式写入的时候: 在rewrite首先保存成RDB(更快),后面使用AOF防止数据丢失和性能(避免阻塞)

注意:AOF不是不丢失数据,只是在缓存中丢失很少,比RDB的全量复制更好

举个例子: AOF相当于签到表有个记录就行,RDB相当于开会,必须全员都来,否则不能开(全量复制)

思考: 主线程,子线程和后台线程的联系与区别?

如下图所示:

• Redis的主线程只有一个:主要用来处理客户端的命令请求,执行相应的操作,并返回对应的结果(多个请求就顺序执行)
• 后台线程: 异步处理,不会阻塞主线程
• 子进程: 是Redis的一个特例,用来Redis的持久化的操作
• 一般而言: 主进程和子进程一般会共用一块内存区域
  • 进程: 作为分配资源的单位,
  • 线程: 是CPU调度和执行的一个实体

思考: Redis的持久化过程有没有一些风险?

答案: 肯定有

• Redis在持久化的fork过程中,会有一些卡顿(因为此过程会产生阻塞)

思考: 为什么主从复制不使用AOF

• 因为作为RDB文件来说,它本身是二进制文件,所以这个文件无论是写入磁盘还是作为网络传输,他的效率都会比AOF高
• 另外: 看下图,就知道,RDB从主到从,采用二进制文件生成快,到从恢复也快,不像AOF采用追加的方式一个一个命令的写入

完结

好了,关于redis的持久化相关知识就分享到这

码字不易,求关注,求点赞啊!~哈哈哈!一起加油,顶峰见!