本文脑图


Redis是一个基于内存的非关系型的数据库,数据保留在内存中,然则内存中的数据也容易发生丢失。这里Redis就为我们提供了持久化的机制,分别是 RDB(Redis DataBase)AOF(Append Only File)


Redis在以前的版本中是单线程的,而在6.0后对Redis的io模子做了优化,io Thread为多线程的,然则worker Thread仍然是单线程。

在Redis启动的时刻就会去加载持久化的文件,若是没有就直接启动,在启动后的某一时刻由继续持久化内存中发生的数据。

接下来我们就来详细领会Redis的两种持久化机制RDB(Redis DataBase)AOF(Append Only File)

RDB持久化机制

什么是RDB持久化呢?RDB持久化就是将当前历程的数据以天生快照的形式持久化到磁盘中。对于快照的明白,我们可以明白为将当前线程的数据以摄影的形式保留下来。

RDB持久化的时刻会单独fork一个与当前历程一摸一样的子历程来举行持久化,因此RDB持久化有如下特点:

  1. 开机恢复数据快。

  2. 写入持久化文件快。

RDB的持久化也是Redis默认的持久化机制,它会把内存中的数据以快照的形式写入默认文件名为dump.rdb中保留。

在安装后的Redis中,Redis的设置都在redis.conf文件中,如下图所示,dbfilename就是设置RDB的持久化文件名。

在这里插入图片形貌
持久化触发时机

在RDB机制中触发内存中的数据举行持久化,有以下三种方式:

(1)save下令:

save下令不会fork子历程,通过壅闭当前Redis服务器,直到RDB完成为止,以是该下令在生产中一样平常不会使用。save下令执行原理图如下:

在这里插入图片形貌
在redis.conf的设置中 dir的设置就是RDB持久化后天生rdb二进制文件所在的位置,默认的位置是 ./,示意当前位置,那里启动redis,就会在那里天生持久化文件,如下图所示:
在这里插入图片形貌
下面我们举行一下实操,演示一下二进制文件天生的历程,在我本机的电脑虚拟机中,我所在的位置如下,该文件夹是新建立的redis的数据存储文件夹。
在这里插入图片形貌
然后我们直接在该位置启动我们的Redis服务,启动的下令如下:


/root/redis-4.0.6/src/redis-server /root/redis-4.0.6/redis.conf

接着通过该下令:ps -aux | grep redis,查看我们的redis服务是否正常启动,若是显示如下图所示,则示意Redis是正常启动的:

在这里插入图片形貌
正常启动后,直接上岸Redis,可以通过以下下令上岸Redis,如下图所示:
在这里插入图片形貌
由于当前中Redis是新安装的,数据都是为空,什么都没有,然后通过下图的下令随意向Redis中输入几条下令,最后执行 save下令,在该文件夹下就会泛起 dump.rdb持久化的数据文件。
在这里插入图片形貌
固然上面说到,在新安装的Redis中默认的RDB数据持久化位置为 ./文件,一样平常我们会把它改成服务器自己的特定位置下,原理都是一样的,可以自己举行实验,这里不再举行演示。


(2)bgsave下令:

bgsave下令会在后台fork一个与Redis主线程一摸一样的子线程,由子线程卖力内存中的数据持久化。

这样fork与主线程一样的子线程消耗了内存,然则不会壅闭主线程处置客户端请求,是以空间换时间的方式快照内存中的数据到到文件中。

bgsave下令壅闭只会发生在fork子线程的时刻,这段时间发生的异常短,可以忽略不计,如下图是 bgsave执行的流程图:

在这里插入图片形貌
上面说到redis.conf中的 dir设置是设置持久化文件天生的指定的目录, dbfilename是设置天生的文件名,也可以通过下令行使用下令来动态的设置这两个设置,下令如下:


config set dir{newDir}
config set dbfilename{newFileName}

(3)自动化

除了上面在下令行使用save和bgsave下令触发持久化,也可以在redis.conf设置文件中,完成设置,如下图所示:

在这里插入图片形貌
在新安装的redis中由默认的以上三个save设置, save 900 1示意900秒内若是至少有1个key值转变,则举行持久化保留数据;


save 300 10则示意300秒内若是至少有10个key值发生转变,则举行持久化,save 60 10000以此类推。

通过以上的剖析可以得出以下save和bgsave的对比区别:

  1. save是同步持久化数据,而bgsave是异步持久化数据。

  2. save不会fork子历程,通过主历程持久化数据,会壅闭处置客户端的请求,而bdsavefork子历程持久化数据,同时还可以处置客户端请求,高效。

  3. save不会消耗内存,而bgsave会消耗内存

RDB的优瑕玷

瑕玷: RDB持久化后的文件是紧凑的二进制文件,适合于备份、全量复制、大规模数据恢复的场景,对数据完整性和一致性要求不高,RDB会丢失最后一次快照的数据。

优点: 开机的恢复数据快,写入持久化文件快。

AOF持久化机制

AOF持久化机制是以日志的形式纪录Redis中的每一次的增删改操作,不会纪录查询操作,以文本的形式纪录,打开纪录的日志文件就可以查看操作纪录。

AOF是默认不开启的,若是像开启AOF,在如下图的设置修改即可:

在这里插入图片形貌
只需要把 appendonly no修改为 appendonly yes即可开启,在AOF中通过 appendfilename设置天生的文件名,该文件名默以为 appendonly.aof,路径也是通过dir设置的,这个于RDB的一样,详细的设置信息如下图所示:
在这里插入图片形貌
AOF触发机制

AOF带来的持久化加倍平安可靠,默认提供三种触发机制,如下所示:

  1. no:示意等操作系统等数据缓存同步到磁盘中(快、持久化没保证)。

  2. always:同步持久化,每次发生数据调换时,就会立刻纪录到磁盘中(慢,平安)。

  3. everysec:示意每秒同步一次(默认值,很快,然则会丢失一秒内的数据)。

AOF中每秒同步也是异步完成的,效率是异常高的,由于该机制对日志文件的写入操作是接纳append的形式。

因此在写入的历程纵然宕机,也不会丢失已经存入日志文件的数据,数据的完整性是异常高的。

在新安装的Redis的设置文件中,AOF的设置如下所示:

在这里插入图片形貌
AOF重写机制

然则,在写入所有的操作到日志文件中时,就会泛起日志文件许多重复的操作,甚至是无效的操作,导致日志文件越来越大。

所谓的无效的的操作,举个例子,好比某一时刻对一个k++,然后后面的某一时刻k--,这样k的值是保持稳定的,那么这两次的操作就是无效的。

若是像这样的无效操作许多,纪录的文件臃肿,就浪费了资源空间,以是在Redis中泛起了rewrite机制。

redis提供了bgrewriteaof下令。将内存中的数据以下令的方式保留到临时文件中,同时会fork出一条新历程来将文件重写。

重写AOF的日志文件不是读取旧的日志文件瘦身,而是将内存中的数据用下令的方式重写一个AOF文件,重新保留替换原来旧的日志文件,因此内存中的数据才是最新的。

重写操作也会fork一个子历程来处置重写操作,重写以内存中的数据作为重写的源,避免了操作的冗余性,保证了数据的最新。

在Redis以append的形式将修改的数据写入老的磁盘中    ,同时Redis也会建立一个新的文件用于纪录此时代有哪些下令被执行。

下面举行演示一下AOF的操作,首先先打开AOF机制,修改设置文件中的appendonly noappendonly yes,然后执行如下图的操作:

在这里插入图片形貌
都显示执行乐成,ls以下查看此时当前的文件夹终究会泛起 appendonly.aof
,AOF的数据持久化文件,通过cat下令查看内容:
在这里插入图片形貌
从上面的存储的文件中可以看出,每一个下令是异常有纪律的,好比第一次执行 key *映射到该设置文件中的下令如下:


*2 //示意该下令两组key 为一组 * 为一组
$6 //示意SELECT有6字符
SELECT
$1 //示意下面的0一个字符
0

然后执行set k1 1的下令,此下令映射到文件中的下令如下:

*3 //示意该下令有三组set为一组 k1为一组 1为一组
$3 // 示意set有三个字符
set // 示意执行了set下令
$2 // 示意k1有两个字符
k1 // key值
$1 // 即是value值的字符长度为1
1  // value值

当AOF的日志文件增长到一定巨细的时刻Redis就能够bgrewriteaof对日志文件举行重写瘦身。当AOF设置文件大于改设置项时自动开启重写(这里指跨越原巨细的100%)。

该设置可以通过如下的设置项举行设置:

在这里插入图片形貌
AOF的优瑕玷

优点: AOF更好保证数据不会被丢失,最多只丢失一秒内的数据,通过foek一个子历程处置持久化操作,保证了主历程不会历程io操作,能高效的处置客户端的请求。

另外重写操作保证了数据的有效性,纵然日志文件过大也会举行重写。

AOF的日志文件的纪录可读性异常的高,纵然某一时刻有人执行flushall清空了所有数据,只需要拿到aof的日志文件,然后把最后一条的flushall给删除掉,就可以恢复数据。

瑕玷:  对于相同数目的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速率比 AOF 的恢复速率要快。AOF在运行效率上往往会慢于RDB。

夹杂持久化

在redis4.0后夹杂持久化(RDB+AOF)对重写的优化,4.0版本的夹杂持久化默认是关闭的,可以通过以下的设置开启夹杂持久化:

在这里插入图片形貌
夹杂持久化也是通过 bgrewriteaof来完成的,差别的是当开启夹杂持久化时,fork出的子历程先将共享内存的数据以RDB方式写入aof文件中,然后再将重写缓冲区的增量下令以AOF方式写入文件中。


写入完成后通知主历程统计信息,并将新的含有RDB花样和AOF花样的AOF文件替换旧的AOF文件。简朴的说:新的AOF文件前半段是以RDB花样的全量数据后半段是AOF花样的增量数据。

优点: 夹杂持久化连系RDB持久化AOF持久化的优点,由于绝大部分的花样是RDB花样,加载速率快,增量数据以AOF方式保留,数据更少的丢失。

RDB和AOF优势和劣势

rdb适合大规模的数据恢复,由于rdb时异快照的形式持久化数据,恢复的数据快,在一定的时间备份一次,而aof的保证数据加倍完整,损失的数据只在秒内。

详细哪种更适合生产,在官方的建议中两种持久化机制同时开启,若是两种机制同时开启,优先使用aof持久化机制。