仓库地址: https://github.com/dengjiayue/my-redis-v2.0-RESP-.git

redis_4">redis的持久化机制与实现原理

• redis的持久化机制有两种RDB(数据快照)与AOF(文件追加)

RDB工作原理

RDB的触发形式有两种,一种是save,一种是bgsave

• save:会阻塞服务器直到持久化完成,期间不接受其他的请求.可能会造成大量的请求积压,影响redis的性能

• bgsave:主线程会fork一个子线程去进行持久化操作,生成新的RDB文件,然后替换旧的文件,通知主线程并退出

问题1:如果数量很大怎么办?

一般会使用bgsave,这样主线程的功能还可以正常运行,如果使用save那么会严重影响redis的功能.

问题2:子线程在持久化期间有新的数据写入会发生什么?如何保证数据一致性?

如果在生成RDB是主线程收到了写操作,这些数据会在新的临时空间储存,等持久化完成才回到原本的空间,查询的话先走临时的空间(最新的数据),再走原本空间.保证查询的是最新的数据.

AOF的原理

• AOF是以文件追加的形式工作的,将收到的请求(写)追加到aof文件中

如何解决aof文件越来越大的问题

• 随着运行时间的变长,写的命令越来越多,aof文件也越来越大
• 解决方案就是给aof文件瘦身: AOF文件重写

aof文件如何重写?

最简单的方式就是只保留最新的结果,中间的去除
比如

set number 1
set number 2
set number 3
.....
set number 1000000

那么我们只需要保留最新的结果,而中间的结果可以去除掉,这样可以减少aof文件的大小

aof如何恢复数据

因为我们储存的是请求的命令(写),那么恢复就是读取aof中的命令重新生成数据就行了

aof文件有问题(损坏了)恢复会发生什么?怎么办?

• redis无法执行损坏的aof文件,会报错
• redis有aof文件修复功能: 就是清除有问题的键值对

aof有哪些模式?

1. 每一个写都追加:每次都持久化到磁盘;安全性好,性能差
2. 1s追加一次:先写到缓冲,每一秒持久化一次磁盘;性能比第一种高很多,有部分数据容易丢失
3. 不主动执行:性能很高,但是不安全

RDB与AOF的优缺点

对服务的影响:

• RDB(bgsave)只有fork子线程会阻塞主线程,对主线程(服务)的影响比较小
• aof每次(写)都会阻塞一下主线程(不写磁盘的除外),特别是每个写都落盘影响最大(写到缓冲器的方式,一秒进行一次同步阻塞很少)

持久化时间与消耗:

• RDB的持久化时间更长,因为需要加载全部的数据写到磁盘,对内存的消耗比较大,时间比较长
• AOF是追加的方式,数据少,时间短,消耗低

文件大小:

• RDB是压缩的二进制的数据,体积小
• AOF是追加的命令体积大(重写了还是很大,而且会越来越大)

参考:https://blog.csdn.net/w15558056319/article/details/121421463