面试官:你知道 redis 是的「怎么做持久化」的吗?
我:我知道 redis 有两种方式,一种是 RDB,一种是 AOF。
面试官:那这两种方式「具体是怎么做」的,它们的「区别」是什么,生产环境中到底应该怎么选择??
我:嗯。。。。。。这个我不知道。
面试官:出门左拐,不送。
嗯。。。以上场景很真实,都说面试造火箭,入职拧螺丝,今天我们就让面试官再问到这个问题时,把他按在地上摩擦!
我们简单的说明一下什么是 redis 的持久化:
用通俗的语言来说.redis 的持久化就是「将内存中的数据,保存的磁盘当中,以便于数据恢复」.
接下来我们进入正题,说说 redis 持久化的方式 redis 的持久化方式有「两种」:
RDB(redis database):
把某个时间点redis内存中的数据以二进制的形式存储的一个.rdb为后缀的文件当中,也就是「周期性的备份redis中的整个数据」,这是redis默认的持久化方式,也就是我们说的快照(snapshot)
这是redis中默认的配置,它的意思就是
在900s内,有1个redis键有变化,就备份一次
在300s内,有10个redis键有变化,就备份一次
在600s内,有10000个redis键有变化,就备份一次
这个参数是我们可以修改的,具体的数值可以根据我们的业务量进行匹配
有意思的是,我们都知道,进程与进程之间的内存不是共享的,那么「子进程是如何获取到主进程的内存数据呢?」
用心的小伙伴可能已经发现了,既然主进程要把自己的数据复制一份给子进程,那么就是说,会有「双倍的内存占用」.
简单点来讲,假如你的redis在未fork子进程时就占用了5G内存,那么你的服务器剩余可用内存「至少要达到」5G才可正常的进行fork操作.
有的小伙伴可能会问,那么「这个复制内存的操作是立即执行的吗」?
又有一个问题来了,「如果在fork期间客户端又发起了新的操作,redis会怎样做呢」?
所以大家也发现了,fork的时间长短其实是跟当时redis中的数据量有很大关系的,在其他条件恒定的情况下,随着「数据量的增大,redis 的fork操作时间也会变」长.
为了性能,基本上 R「edis 内部所有的 RDB 操作都是采用 bgsave 命令」,也就是自动提交。
RDB的优点:
RDB的缺点:
AOF(append only file): redis每次执行一个命令时,都会把这个「命令原本的语句记录到一个.aod的文件当中,然后通过fsync策略,将命令执行后的数据持久化到磁盘中」(不包括读命令)
我们知道 AOF 是不断的将「写命令追加」到一个后缀叫 .aof 的文件当中的,那么问题来了,随着我们不断的写命令,aof文件越来越大,那么redis会做什么操作呢? 我们举个简单的例子.
set a 10
del a
set a 10
del a
我们执行了以上四条命令,正常来说,就会在.aof文件当中存在这四条命令的身影,但是我们发现,其实当我们执行完这四条命令,我们根本没有修改数据的内容,要知道,redis的本质就是存储数据的,「只要数据内容不发生改变,即使做再多的操作也是没有意义的」.
redis自然也考虑到了这一点,所以它会自己对.aof文件进行优化,「重建.aof文件」.
这个文件中包含了当前数据所需要的的最少的命令集 (如:a + 1,a + 1,a + 1 这三个命令会合成为a + 3 这一个命令).
当然redis并「不会让主进程进行这个操作」,为了防止阻塞,在执行重写操作期间会设置一个「aof重写缓冲区」,仅仅用于在后台进程重写期间,将发生的数据库读写命令写入到重写缓冲区,之后当重写子进程完成重写后,向服务器主进程发送一个信号,此时服务器主进程将aof重写缓冲区中的命令追加到新的aof文件中去,用新的aof文件替换掉旧的aof文件。
redis有两种持久化的方式,一种是RDB,一种是AOP
所谓RDB就是段时间的用快照的方式将redis中的所有数据存储下来,并且通过fork子进程的方式去持久化的,由于redis通常是用来读取数据的,所有中间有一层优化就是写时持久化(进程与进程之间内存不共享,再redis数据发生变动时再fork完成持久化)
而AOF就是存储一条条执行的redis命令(不包括查询命令),通过命令的方式完成持久化,并且中间还会有AOF重写的操作,主要就是为了节省空间。