redis源码分析(五):数据持久化

redis 是基于内存读写的数据库,所有数据都存储在内存中,所以存储的数据大小受到了限制。但redis依然提供了固化功能,与mysql,leveldb等数据库不同的是,redis的存储功能只是用做备份,恢复的功能,全量数据还是存储在内存中。
redis内部提供了两种固化数据的方式,aof 和rdb。

1.aof

数据写入

aof全称appendOnlyFile,要让redis支持aof方式,需要将配置文件的appendonly配置为"yes",并配置appendfsync 为everysec/always/no。everysec是redis推荐的配置,我们默认以这种方式来具体分析。
每次对数据有修改的操作,均会以append的方式写入server.aof_buf中,每秒钟将在时间事件中检查这个缓冲区是否为空,不空则说明有新的更新,将其写入aof文件中(注意write函数并非实时写入硬盘,可以用flush函数来强制刷新未写入的缓存),并触发刷新任务,通知bio模块创建的线程中执行。aof的文件是相对"白话"的,如图是我本地截取的aof文件:

redis源码分析(五):数据持久化_第1张图片

 

'*'后跟的是当前的参数个数,'$'后跟的是下一个参数的长度,再后来就是参数了。一个redis中有多个数据库,我们需要确定数据增改到那个数据库了,因此第一句为select db的操作。

除了手动配置的刷新aof规则外,客户端可以手动触发bgrewriteaof来覆盖已有的aof文件(未开启aof配置也是支持这个命令),客户端发起此命令后,redis会fork一个子进程来将内存中的数据保存到文件中。那么问题来了,子进程运行过程中,redis主进程依然在提供服务,如果期间写入新的数据,那么主子进程间的数据将会不同步,如何解决?期间的数据会存储在链表数据块server.aof_rewrite_buf_blocks中,当主进程用wait方法检测到子进程退出以后,会调用backgroundRewriteDoneHandler函数,将缓存的数据附加到新的aof文件中。重写aof可以减小aof文件的大小,因为部分数据失效,或者来回更改,在everysec的配置中均会保存下来,但是重写aof之后,无效数据,或者中间状态的修改均会被忽略。

数据载入

redis刚启动的时候会优先检查是否开启aof配置(否则rdb),如果是则加载aof配置文件,每个参数均以'\n'结尾,因此读取/判断合法十分方便。创建一个fakeClient来模拟客户端将数据插入内存中。这里有一个疑问,数据载入的同时,服务依然处理客户端的io任务,这样不怕aof的旧文件写脏用户新插入的数据么

2.rdb

数据写入

用户可以配置redis中save的参数,格式为save sec commit 代表每sec秒,如果有commit次修改,则由服务自身执行一次bgsave操作。save配置可以有多个,相互之间是或的关系。server.dirty用来记录数据修改次数,bgsave完成以后,会将其置0。
redis的每次写入都是全量操作,步骤如下

  • 1.创建临时文件,写入redis字符串+版本号。

  • 2.写入select db语句,如果当次db没有数据,跳到下一个,没有更多数据库了,跳到步骤5。

  • 3.创建字典的迭代器,循环字典内的元素。

  • 4.redis都是键值对数据,分别写入超时时间(如果有的话),value的类型,key,value,其中key和value尽可能的压缩编码。如果迭代器到达结尾,跳到步骤2。

  • 5.大于4的版本加入了校验码,校验和使用crc计算,用临时文件覆盖正式rdb文件,流程结束。

数据载入

这个也没有悬念了,怎么写入,就怎么加载;读取到数据之后直接调用dbAdd函数把数据插入到字典server.db[dbnum]->dict中。

对比下aof和rdb。

1.aof文件相对于直接保存了语句和中间过程。所以更易于开发者修改查看数据。追加修改的命令,对io,cpu,内存压力均较小,相对来说更吃存储空间。
2.aof的缺点就是rdb的优点了。特别是如果rdb的save参数保存不当,redis会频繁执行bgsave命令,每次都是全量修改,在数据量大,修改频繁的时候会是个灾难。

 

 

 

 

 

 

 

 

 

 

 

你可能感兴趣的:(redis)