《Redis源码走读及编程实践——数据安全篇(一)》介绍了RDB的落地原理并走读了redis的RDB落地流程,本文继续介绍redis的另外一种数据落地机制AOF,从配置、原理三个角度介绍redis的AOF机制。因笔者能力有限,行文观点若有疏漏,恳请指正。更多后台开发文章移步:作者个人博客
如前所述,redis采取RDB的方式进行全内存镜像备份;但是这种方式开销大,不能频繁进行;为了降低数据丢失,redis采取记录操作流水的形式记录客户端每次对redis-server数据的修改,也就是AOF(Append Only File)。关于AOF,主要需要关注以下几个问题:
Redis-server配置中和AOF相关的配置如下图:
Redis官方对于各个配置项的解释很清楚,这里简要介绍一下,具体可以参考redis发布包配置文件中的说明文档:
所谓AOF(Append Only File)是redis在RDB之外的一种数据落地机制,区别于RDB全量备份内存镜像,AOF机制采取的是记录操作流水的方式实现数据落地,因此可以实践秒级甚至可以完全的无数据丢失。
Redis中,AOF落地其实分为三步:首先是写数据到AOF数据缓存区,然后是将数据从用户缓存区通过系统调用复制到内核缓存区,此时进程挂掉数据不会丢失,但是机器掉电或者系统崩溃会导致数据丢失;最后是写文件的数据从内核缓存区真正写入到磁盘,此时真正意义数据落地;可以通过手动调用flush和fsync强制数据刷到内核缓存区和强制数据落磁盘。
在redis中feedAppendOnlyFile完成上述流程的第一步,而flushAppendOnlyFile完成数据落内核缓存区和写磁盘两步:依次来看,首先是feedAppendOnlyFile接口:
数据flush并没有完全实际意义上的数据落地,flushAppendOnlyFile才是实际完成数据落磁盘:
关于AOF数据落地,需要关注以下几点:
由于AOF记录的是redis的操作流,则必然存在很多冗余信息;时间长了,会导致AOF文件过大,既占用了存储空间又导致了重启进程的时候重建数据时间过长,为此redis采取AOF重写的方式来消除冗余数据;如前所述,触发AOF重写有两个维度,一个是文件大小;另外一个是文件的增长比例;在此,我们着重看AOF重写流程:
AOF重写的核心接口与流程已经在上面截图中有所论述,我们针对其中的一些需要注意的点进行说明:
在redis server启动的时候,会加载磁盘数据,根据配置项中的AOF开关,判断是加载RDB文件还是AOF文件,分别通过不同的接口rdbLoad和loadAppendOnlyFile实现;关于AOF文件的加载,核心代码的流程如下部分代码截图所示;这里归纳一下需要注意的地方:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。