【大厂面试 06 期】谈一谈你对 Redis 持久化的理解?

发布于: 2020 年 06 月 18 日
【大厂面试06期】谈一谈你对Redis持久化的理解?

PS:本文已收录到1.4 K+ Star 数的开源项目《大厂面试指北》,如果想要了解更多,可以访问Github项目主页:

https://github.com/NotFound9/interviewGuide

获取《大厂面试指北》PDF版,请扫描下方二维码进技术交流群获取,欢迎进群一起玩耍,一起学习进步!

摘要

Redis持久化是面试中经常会问到的问题,这里主要通过对以下几个问题进行分析,帮助大家了解Redis持久化的实现原理。

1.Redis持久化是什么?

2.Redis持久化有哪些策略?各自的实现原理是怎么样的?

3.Redis的数据恢复策略是怎么样的?

4.Redis持久化策略该如何进行选择?

1.Redis持久化是什么?

因为Redis是一个内存数据库,数据保存在内存中,一旦发生关机或者重启,内存中的数据都会丢失,所以为了能够重启时恢复数据,Redis提供了持久化的机制,正常运行期间根据策略生成持久化文件。在机器重启后,可以根据根据持久化文件恢复内存中的数据。Redis还为我们提供了持久化的机制。(虽然有主从同步,主机挂掉之后,可以让从节点成为主节点,但是如果整个机房都发生停电,那么主节点和从节点内存中的数据都会丢失,所以这也是持久化存在的意义。)

2.Redis持久化有哪些策略?

Redis持久化的策略主要有AOF持久化,RDB持久化,混合持久化。这是我自己总结的一个图:

AOF持久化

执行流程

AOF持久化主要是Redis在修改相关的命令后,将命令添加到aof_buf缓存区的末尾,然后在每次事件循环结束时,

根据appendfsync的配置:

  • appendfsync = always 每条修改命令都会更新到磁盘上的AOF文件, 最多只会丢失当前正在写入的命令

  • appendfsync = everysec 每秒更新到磁盘上的AOF文件一次, 最多丢失2秒的数据(因为执行fsync命令刷盘也需要时间,下面会解释)

  • appendfsync = no 不自动更新到磁盘上的AOF文件,由操作系统来决定何时刷盘(linux 貌似大部分默认是 30s)。可能会丢失刷盘之前的写入数据。

(基于性能考虑一般生产环境的配置都是everysec)

(aof_buf是Redis中的SDS结构,可以理解为是一个字符串,只是对C语言的字符串做了一些优化,每次将新执行的更新命令添加到字符串末尾。)

怎么防止AOF文件越来越大?

为了防止AOF文件越来越大,可以通过执行BGREWRITEAOF命令,会fork子进程出来,读取当前数据库的键值对信息,生成所需的写命令,写入新的AOF文件。在生成期间,父进程继续正常处理请求,执行修改命令后,不仅会将命令写入aofbuf缓冲区,还会写入重写aofbuf缓冲区。当新的AOF文件生成完毕后,子进程父进程发送信号,父进程将重写aof_buf缓冲区的修改命令写入新的AOF文件,写入完毕后,对新的AOF文件进行改名,原子地(atomic)地替换旧的AOF文件。

什么是AOF文件追加阻塞?

修改命令添加到aofbuf之后,如果配置是everysec那么会每秒执行fsync操作,调用write写入磁盘一次,但是如果硬盘负载过高,fsync操作可能会超过1s,Redis主线程持续高速向aofbuf写入命令,硬盘的负载可能会越来越大,IO资源消耗更快,所以Redis的处理逻辑是会对比上次fsync成功的时间,如果超过2s,则主线程阻塞直到fsync同步完成,所以最多可能丢失2s的数据,而不是1s。

RDB持久化

RDB持久化指的是在满足一定的触发条件时(在一个的时间间隔内执行修改命令达到一定的数量,或者手动执行SAVE和BGSAVE命令),对这个时间点的数据库所有键值对信息生成一个压缩文件dump.rdb,然后将旧的删除,进行替换。

执行流程

实现原理是fork一个子进程,然后对键值对进行遍历,生成rdb文件,在生成过程中,父进程会继续处理客户端发送的请求,当父进程要对数据进行修改时,会对相关的内存页进行拷贝,修改的是拷贝后的数据。(也就是COPY ON WRITE,写时复制技术,就是当多个调用者同时请求同一个资源,如内存或磁盘上的数据存储,他们会共用同一个指向资源的指针,指向相同的资源,只有当一个调用者试图修改资源的内容时,系统才会真正复制一份专用副本给这个调用者,其他调用者还是使用最初的资源,在CopyOnWriteArrayList的实现中,也有用到,添加或者插入一个新元素时过程是,加锁,对原数组进行复制,然后添加新元素,然后替代旧数组,解锁)

//CopyOnWriteArrayList的添加元素的方法
public boolean add(E e) {
final ReentrantLock lock = this.lock;
lock.lock();
try {
Object[] elements = getArray();
int len = elements.length;
Object[] newElements = Arrays.copyOf(elements, len + 1);
newElements[len] = e;
setArray(newElements);
return true;
} finally {
lock.unlock();
}
}

混合持久化(Redis4.0+)

执行流程

混合持久化同样也是通过bgrewriteaof命令完成的,不同的是当开启混合持久化时,fork出的子进程先将当前内存中的键值对信息全量的以RDB方式写入aof文件,然后在将重写缓冲区的增量命令以AOF方式写入到文件,写入完成后通知主进程更新统计信息,并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说:新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据,如下图:

3.Redis的数据恢复策略是怎么样的?

1.如果配置了混合持久化,那么根据混合持久化文件进行恢复数据。(Redis4.0+)

2.只配置 AOF ,重启时加载 AOF 文件恢复数据。

3.同时配置了 RDB 和 AOF ,启动时只加载 AOF文件恢复数据,如果AOF文件损坏,那么根据RDB文件恢复数据。

4.只配置 RDB,启动时加载RDB持久化文件恢复数据。

4.Redis持久化策略该如何进行选择?

(因为混合持久化是Redis 4.0之后支持的,目前一般生成环境使用的Redis版本可能都还较低,所以这里的策略选择主要是针对AOF持久和RDB持久化进行技术选型。)

以下是几种持久化方案选择的场景:

1.不需要考虑数据丢失的情况

那么不需要考虑持久化。

2.单机实例情况下

可以接受丢失十几分钟及更长时间的数据,可以选择RDB持久化,对性能影响小,如果只能接受秒级的数据丢失,只能选择AOF持久化。

3.在主从环境下

因为主服务器在执行修改命令后,会将命令发送给从服务器,从服务进行执行后,与主服务器保持数据同步,实现数据热备份,在master宕掉后继续提供服务。同时也可以进行读写分离,分担Redis的读请求。

那么在从服务器进行数据热备份的情况下,是否还需要持久化呢?

需要持久化,因为不进行持久化,主服务器,从服务器同时出现故障时,会导致数据丢失。(例如:机房全部机器断电)。如果系统中有自动拉起机制(即检测到服务停止后重启该服务)将master自动重启,由于没有持久化文件,那么master重启后数据是空的,slave同步数据也变成了空的。应尽量避免“自动拉起机制”和“不做持久化”同时出现。

所以一般可以采用以下方案:

主服务器不开启持久化,使得主服务器性能更好。

从服务器开启AOF持久化,关闭RDB持久化,并且定时对AOF文件进行备份,以及在凌晨执行bgaofrewrite命令来进行AOF文件重写,减小AOF文件大小。(当然如果对数据丢失容忍度高也可以开启RDB持久化,关闭AOF持久化)

4.异地灾备

一般性的故障(停电,关机)不会影响到磁盘,但是一些灾难性的故障(地震,洪水)会影响到磁盘,所以需要定时把单机上或从服务器上的AOF文件,RDB文件备份到其他地区的机房。

发布于: 2020 年 06 月 18 日 阅读数: 80
用户头像

NotFound9

关注

infoQ特邀作者,某大厂高级开发工程师 2018.05.06 加入

Github 1.2K+ Star数的开源项目interviewGuide作者 《大厂面试指北》Github主页:https://github.com/NotFound9/interviewGuide

评论

发布
暂无评论
【大厂面试06期】谈一谈你对Redis持久化的理解?