面试被问到Redis的持久化策略别再不会啦

前提概念

  • 持久化的作用

  • Redis持久化的方式

RDB持久化策略

  • 什么是RDB?

  • RDB的两种策略方式

  • 如何使用RDB策略备份数据?

  • RDB的原理是什么?

AOF持久化策略

  • 什么是AOF

  • AOF的原理是什么

  • AOF的三种策略

  • AOF的重写机制

RDB和AOF的抉择

  • RDB还是AOF?

  • Redis4.0的混合持久化

  • 运维最佳实践

其他问题

  • RDB持久化操作时,子进程拷贝父进程的数据副本用于持久化,不会增加内存消耗吗?

  • 为什么Redis的AOF机制是先成功命令才再记录日志?

  • AOF文件过大会怎么办?

前提概念

持久化的作用

什么是持久化?

  • 我们将能把内存中的数据保存到磁盘中存储的行为就称之为持久化

为什么需要持久化?

  • Redis所有的数据保存在内存中,如何Redis实例突然的宕机,其占用的全部内存就会被系统释放,导致Redis的数据全部丢失,因此必须要有一种机制来保证Redis的数据不会因为故障而丢失。这一机制就是Redis的持久化机制。

  • 所以持久化操作的作用就是把Redis中的数据,保存到磁盘中。避免因为实例宕机,而出现数据丢失的现象。

Redis持久化的方式

Redis为我们提供了主要的两种持久化方式

  • 数据快照 (RDB)
    这种行为就类似MySQL的Dump ,redis的RDB,这就是某时某个点的全部数据备份

  • 日志文件(AOF)
    每次的操作就写入日志,当我们需要恢复数据时,就可以根据日志的记录完整的走一遍流程,恢复数据,比如MySQL的BinLog,Hbase的HLog,Redis的AOF

RDB持久化策略

什么是RDB?

什么是RDB数据快照?

  • RDB文件是一个二进制文件,存储在硬盘当中。其实就是之前用过的MySQL dump,我们把某个时刻的数据导出成RDB文件,需要的时候,导回去恢复数据即可

RDB的两种策略方式
  • save(同步)
    我在redis client执行save命令,它就会在Redis安装目录下生成一个RDB文件,在数据量比较大的时候,会造成一个同步阻塞。如果存在老的RDB文件,则替换。时间复杂度是O(n)

  • bgsave命令(异步)
    使用了linux的fork()函数生成了主进程的子进程,让这个子进程去完成RDB的生成。生成完毕后,会通知主进程,我们的RDB文件生成成功了。时间复杂度也是O(n),只不过不阻塞主进程

如何使用RDB策略备份数据?

支持自动,手动两种方式进行RDB持久化

redis可以通过客户端主动持久化,输入命令,生成RDB文件,也可以通过配置来等满足条件时自动持久化,生成RDB文件

通过客户端输入config get dir就可以知道Redis的数据存放路径。
通过客户端输入config get dbfireaname就可以知道rdb文件的名称

面试被问到Redis的持久化策略别再不会啦_第1张图片

  • 手动持久化
    手动在客户端输入save 或 bgsave命令

  • 自动持久化
    通过配置,使得Redis在某个条件的时候自动触发RDB文件的生成,比如save m n配置
    save 900 1 900秒内至少有1个key被改变则做一次快照

    save 300 10 300秒内至少有300个key被改变则做一次快照

    save 60 10000 60秒内至少有10000个key被改变则做一次快照

什么情况下会主动触发Redis的RDB快照机制呢?

  • 主从复制时,从库全量复制同步主库数据,此时主库会执行bgsave命令进行快照;

  • 客户端执行数据库清空命令FLUSHALL时候,会触发快照的生成

  • 客户端执行shutdown关闭redis时,会触发快照的生成

RDB的原理是什么?

(一) RDB文件如何生成?

  • RDB快照文件即使就类似MySQL的DUMP文件,它就是一个快速数据,对某个时间节点的数据来个快照,然后备份到磁盘中。

  • 说白了当你要进行快照持久化时,Redis就会遍历内存中的所有数据,然后将数据序列化后写入到磁盘中的RDB文件


(二) 单线程模型的Redis进行RDB持久化,难道不会阻塞其他业务请求吗?

我们知道RDB持久化策略就是Redis在某个时间节点,扫描内存中的所有数据,生成一个二进制RDB文件,保存到本地。但是我们知道Redis是单线程模型的进程,既单个线程在处理客户端请求的同时,还要花点时间处理持久化生成RDB文件的耗时操作。那么问题就来了,生成RDB文件如此耗时,那么持久化的过程不就会阻塞我们正常的业务请求了吗?

答案是肯定会的,所以Redis为了解决这个问题,采用的是操作系统中的多进程COW机制 (Copy On Write) 来实现快照持久化

(三) 多进程COW机制 (Copy On Write)原理

什么是Copy On Write?

  • 相信Copy On Write这个名词,应该很多开发人员都知道,其作用就像Java中的CopyOnWriteArrayList的数据结构一样。当有人要写一个cow对象时,我们不会直接在该对象进行操作,而是复制一份它的副本数据,对该副本进行写操作,最后将修改后的副本替换原数据。它的作用就是可以实现对cow对象做到并发读-写不冲突,读-读不冲突。唯有写写才冲突

那什么又是多进程Copy On Write呢?

  • 我们都知道Redis是单线程模型,意思就是单个进程单个线程。但是实际上,Redis并非真的是单进程/线程的去处理事情。既主要的工作的确是单进程/线程模型,但也有一些很重要的,但比较耗时的操作,Redis并不是交给主进程/线程去做的,而是扔个子进程/线程去做异步操作!!

  • 既Redis在持久化时会调用glibc的函数,从主进程中fork出一个子进程,RDB快照持久化操作就是完全交给子进程异步去实现,而父(主)进程依然正常的继续处理客户端的业务请求。这里描述的就是多进程的体现

  • 而Copy On Write的体现就在于,RDB持久化操作,生成的是某一个时间节点的数据。比如我在12:00开始生成快照,那么不管之后Redis是否又对内存的数据做了什么操作,但我的RDB数据快照就一定是12:00这个时刻的数据。所以如果在12:00之后,还有其他客户端的写操作请求,那么Redis的父进程就会拷贝一份12:00的完整副本数据,专门用于做数据修改,而原数据则被子进程用于做RDB持久化的操作。所以主线程在12:00之后对数据的增删查改,是不会反应到快照数据中的。

AOF持久化策略

什么是AOF?
  • AOF就是一个日志文件,对Redis的每一条命令都会以AOF格式写入AOF文件中。需要恢复时,就导入AOF文件去执行里面的记录就可以了,而且记录肯定是实时的,毕竟每执行一条命令就会有相应的纪录

  • AOF日志存储的是Redis服务器的顺序指令序列,AOF日志只记录对内存进行修改的指令

  • AOF日志的记录并不像MySQL, HBase等数据库先写入日志再执行操作,而是先执行成功命令,再将命令记录到日志文件中。

  • 通过在配置文件配置appendonly参数为yes, 以开启AOF持久化

AOF的三种策略

(一) AOF写入原理

我们知道了Redis的AOF文件实际就是记录Redis实例的所有涉及修复内存的指令,但是我们要记录一个记录日志的特性

  • 但是这些修改指令的记录并不是直接刷到磁盘文件中的,而是①首先将内容写入内核的内存缓冲区,②然后再根据策略从内核异步刷新到硬盘的AOF文件中。

  • 这是为什么呢?因为这是一个效率问题,如果直接写入硬盘,速度较慢,有瓶颈。所以先写入缓冲区,保证吞吐量,然后再异步的刷新到硬盘中

(二) AOF写入的三种策略

所以Redis给我们提供了三种AOF策略,以供用户按需选择

  • always
    实时刷新,将缓冲区的每一条命令都立即刷新到硬盘的AOF文件。既每执行一条命令,待其刚刷入缓冲区,就立即强制刷入磁盘AOF文件中

  • everysec
    每一秒执行一次,既每一秒都强制将缓冲区的内容刷新到硬盘AOF文件中。

  • no
    不强制刷入,no就是不需要我们来考虑什么时候刷入磁盘,而是由操作系统来决定,他想什么时候刷新就什么时候刷新

(三) 三种策略的优缺点比较

  • always实时刷新策略的好处是可以保证,AOF文件是实时更新的,可以保证AOF日志肯定是完整的,不会出现AOF日志内容丢失的情况。但是缺点也很大,就是每次写操作,就要立马刷入日志,使得Redis的内存操作者和磁盘IO操作被同步捆绑,以至于产生大量的同步IO操作,造成Redis的写性能严重下降。影响了Redis高性能的口碑

  • everysec每秒一次策略,可以保证AOF文件每秒都能刷入一批指令记录。既在安全性和性能上进行平衡考虑的折中策略。好处就是在保证性能的同时,一定程度的保证数据的持久性,最多丢失1s的数据。缺点就是在高并发的场景下,1s中也可能会产生大量缓存数据,丢失1s的重要数据可能会造成生产事故

  • no这个机制比较少用,因为基本上都不能用在生成环境中。因为同步日志的时间间隔不能确定,完全靠操作系统自主决定。所以一旦宕机,可能会丢失一段时间的数据。

这三种策略的写回时机,以及优缺点汇总在了⼀张表格⾥,以⽅便你随时查看。

面试被问到Redis的持久化策略别再不会啦_第2张图片

RDB和AOF的抉择

RDB还是AOF?

(1) RDB模式的优缺点

优点:

  • RDB快照非常适合做数据备份,因为RDB数据文件非常的紧凑,同样的数据大小,相比AOF日志会更小,节省磁盘空间。

  • RDB快照恢复起来,也比AOF日志要更快

缺点:

  • 生成RDB文件,通常是遍历整个内存数据块,所以即使是fork的子进程去做,也需要一定的资源消耗,时间可能会比较长。

  • 因为生成一个完整的RDB快照数据文件,需要一定的时间,比如几分钟。而且在RDB快照生成期间,此时如果有数据的改动,是不再会反应到RDB文件中的,所以一但数据库宕机,就可能丢失几分钟的数据。既数据安全性没有AOF日志高

  • RDB数据文件,可读性差,不能直接打开

(2) AOF模式的优缺点


优点:

  • AOF支持三种持久化策略,可以使用fysnc函数强制内核刷新缓存到AOF日志中,相比RDB模式,AOF可以更好的保护数据不丢失。

  • AOF日志文件可读性好,可以使用文本工具直接打开,执行了什么修改指令, AOF日志就记录什么。方便查看

缺点:

  • 对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大。

  • 通过AOF日志文件进行数据恢复所需要的时间会更长,相比RDB模式,宕机的Redis实例恢复时间过长,就需要耽搁一段时间

(3) 选择?!

  • 如果你只是需要一个数据备份,不太在乎一小部分数据的丢失,那么你可以使用RDB模式。并且RDB文件也便于迁移,放到多个实例中进行数据恢复

  • 如果你相比之下,更在乎数据的完整性,既更看重数据的不丢失,那么你就可以使用AOF模式

Redis4.0的混合持久化模式

我们知道,如果采用RDB持久策略,一旦Redis宕机,就有可能丢失大量数据。但如果我们使用AOF持久策略,使用AOF日志重放的方式,一旦AOF日志大了,想比RDB的恢复耗时就显的非常慢。所以为了解决这样纠结的问题,Redis 4.0 带来了一个新的持久化特性 “混合式持久化”

面试被问到Redis的持久化策略别再不会啦_第3张图片

什么是混合式持久化策略?

  • 混合式持久化策略,就是不再是单独的RDB快照模式或AOF日志文件模式,而是同时采用RDB快照和AOF日志两种持久化模式的混合持久化模式。具体表现就是会将RDB文件内容和增量的AOF文件内容都存放在同一个文件中(同一个aof格式文件)。

  • 因为RDB快照数据和AOF日志数据都存在同一个文件中,所以该aof格式文件就不再只存放全量的AOF日志了,而是前面的大部分存储的是RDB的快照数据,后一小部分存储的是自RDB快照持久化开始到持久化结束的这段时间发生的增量AOF日志。所以通常是RDB数据占了大头,AOF日志只是一小部分的增量日志

  • 在混合式的持久化策略下,当宕机的Redis实例重启时,会先加载RDB快照的内容,然后再重放增量的AOF日志。这样就可以替代之前的RDB全量导入或AOF全量重放啦!因此重启效率也大幅提升

  • 通过配置参数aof-use-rdb-preamble就可以开启混合式持久化方式,可以通过 config get aof-use-rdb-preamble命令来检查

混合持久化策略的优缺点

优点:结合了RDB和AOF的优点,使得数据恢复的效率大幅提升,有种“鱼和熊掌都可得兼”的感觉

缺点:兼容性不好,redis-4.x新增,虽然最终的文件也是.aof格式的文件,但在4.0之前版本都不识别该aof文件,同时也因为前部分是RDB格式,阅读性很差。

运维最佳实践
  • 快照是通过fork子进程来执行的,它是一个比较耗时的操作,大块写磁盘会加重磁盘负载。默认持久化不建议只使用RDB的方式。建议使用AOF模式或混合式持久化模式

  • AOF的方式有三种策略,不建议在生产环境中使用always, 因为fysnc是一个耗时的IO操作,它会降低Redis的性能。也不建议使用no策略,因为让操作系统来决定如何同步磁盘,这时间可长可短,不安全,所以建议使用everysec策略

  • 在集群环境中,不建议使用Redis的主节点都进行持久化操作,而是放到其从节点进行。因为从节点是备份节点,一般没有来自客户端的请求压力,所以它的操作系统资源一般都比较充沛

  • 做完缓存集群的网络和资源监控检查,同时要注意一点的是,要给Redis实例所在的机子预留一部分的内存,用于给fork的子进程使用

其他问题

RDB持久化操作时,子进程拷贝父进程的数据副本用于持久化,不会增加内存消耗吗?

我们知道了解到,Redis的RDB持久化是基于多进程COW机制实现的。我们也简单的讲解了Copy On Write是什么。但是Redis的多进程COW机制也并非就仅仅是复制数据副本来生成数据快照这么简单的,之前说的这么简单,只是为了更容易理解

那么,那么复杂的情况是怎么个样子呢?

  • RDB持久化操作期间,由子进程在做数据持久化,子进程并不会修改现有的内存数据结构,它只是对内存数据结构进行遍历读取,然后序列化写到磁盘中。然而父进程则不同,因为即使持久化期间,也可能会多个客户端还在不断的向Redis发送读写请求,所以父进程需要不断的对内存数据结构进程修改和更新操作。

因为子进程生成的数据快照肯定是某个时间节点的,而父进程可能又在时刻改变子进程要扫描的内存数据结构,那怎么办呢?

  • COW机制中的父子进程并非是完全独立的进程,他们之间的关系更像是一个连体婴儿,虽然是两个进程,但是实际在子进程刚刚被fork出来的时候,父子进程实际共享的是同一段内存空间,就相当于有两个头,但却共享一个身体,不过之后还是会慢慢剥离的,前期只是为了尽量共享,节约资源。

  • 此时Redis,就会使用操作系统的COW机制进程数据段页面的分离(数据段是有很多操作系统的页面组合而成)。当父进程对其中一个页面的数据进行修改的时候,会将被共享的数据页面复制一份分离出来,然后对这个复制的页面进行修改。此时子进程想应的页面是没有变化的,依然是子进程产生时那一刻的数据

  • 随着父进程接收的写请求越来越多,要复制出来修改的共享页面也越来越多。所以此时内存就会持续增长,但是由于被修改数据的比例一般占Redis总数据的比例不会太大,所以内存也不会增加原来两倍的情况。当然如果你在持久化期间,全部数据都被修改了个遍,那么两倍内存还是有希望的。

为什么Redis的AOF机制是先成功命令才再记录日志?
  • 如果Redis是先写日志后执行命令的话,可能会导致很多的错误命令都被记录到AOF文件中,这回加重AOF日志的负担

AOF文件过大会怎么办?

  • AOF文件会重写。简单来说,AOF重写机制就是在重写时,Redis根据数据库的现状创建⼀个新的AOF⽂件,也就是说,读取 数据库中的所有键值对,然后对每⼀个键值对⽤⼀条命令记录它的写⼊。重写机制具有“多变⼀”功能。所谓的“多变⼀”,也就 是说,旧⽇志⽂件中的多条命令,在重写后的新⽇志中变成了⼀条命令。

你可能感兴趣的:(redis,面试,redis,adb)