<返回更多

探索Redis持久化原理

2020-03-05    
加入收藏

RDB(默认)

RDB是通过快照方式完成的,当满足一定条件时,redis会自动将内存中的数据持久化到磁盘。

触发快照的时机

###快照设置规则 save {多少秒内} {数据变化了多少}

例如:save 100 1:在100秒内,至少有一个键被修改就进行快照;save 200 4:在200秒内,至少4个键被修改就进行快照。

RDB的优缺点

AOF方式

默认情况下,redis是没有开启AOF(Append only file)的。在开始AOF之后,redis每接收到一条更改redis数据的命令,就会将该命令写入硬盘中的AOF文件。很明显,该过程会降低redis的性能,但大部分情况下是能够接受的,同时,使用性能较好的硬盘可以提高AOF性能

AOF配置方式

# 开启appendonly参数appendonly true# 设置AOF文件位置dir ./# 设置AOF文件名称,默认是appendonly.aofappendfilename appendonly.aof<br data-filtered="filtered">

RESP协议

Redis客户端使用RESP协议与Redis服务端进行通信,该协议是专门为redis设计的,但是也可以用于其他C-S项目。

AOF原理说明

redis通过将所有的写入命令记录到AOF文件中,来持久化数据。而将命令记录到AOF文件的过程,可以分成三个阶段:

命令传播

redis将执行完的命令,命令参数,命令参数格个数等内容发送到AOF程序。当redis客户端执行命令的时候,通过连接,将协议文本发送到redis,redis接收到协议文本之后,根据内容,选择适当的命令函数,将协议文本转换成Redis字符串对象,在命令函数执行完成后,将命令参数发送到AOF程序。

缓存追加

AOF程序接收到命令参数之后,会将其从字符串对象转换成协议内容,再将协议内容追加到AOF缓存中。AOF缓存是在redisServer结构的aof_buf中,新的内容会被追加到aof_buf末尾。aof_buf保持着所有未被写入到AOF文件的协议文本。

文件写入和保存

将AOF缓存内容写入到AOF文件,并保持到磁盘。 当服务器的常规函数被执行,或者事件处理器被执行的时候,flushAppendOnlyFile函数将会被执行。会有以下两个过程。

AOF一共有三种保存模式

AOF的文件优化

Redis可以在AOF文件过大的时候,在后台(子进程)对AOF文件进行重写。重写之后的新文件,包含恢复当前数据集所需的最小命令集合。重写,并不会对AOF文件进行读取和写入,针对的是数据库中的当前键。

优化前set s1 1set s1 2set s1 3优化后set s1 3<br data-filtered="filtered">

AOF文件优化原理

AOF的重写是通过子进程实现的,因此,主线程是继续工作的,有可能对新的数据进行修改,有可能会导致数据库的数据和重写之后的数据不一致。redis通过增加一个AOF重写缓存来解决这个问题,当fork出子进程之后,新的命令不仅会追加到现有的AOF文件中,还会添加一份数据到这个缓存当中。

重写过程分析(需要保证从写的操作是绝对安全的)

Redis创建新的AOF文件之后,会继续将命令添加到原有的AOF文件中,即使数据库突然宕机了,原有的AOF文件和文件内容也不会有损失。而当新的AOF文件创建完毕之后,会直接把旧的替换掉,往新的AOF文件中添加命令。

当子进程在进行重写时,主进程会完成下列工作

这样程序就完成了新旧AOF文件的替换工作。而当处理完成之后,主进程就会继续接受请求。整个重写过程中只有最后的缓存写入和改名替换的操作会导致主进程阻塞,其他时候不会影响redis的正常工作,把AOF重写对redis的性能影响降到最低。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍最近更新
更多资讯 >>>