Redis的持久化

目录

RDB

手动触发

bgsave的执行过程

自动触发 

AOF 

AOF的执行流程 

重写机制 

重写的流程 

混和持久化 

比较AOF和RDB 

RDB

手动触发

1.save

这个命令会全力以赴地生成“快照”,如果数据量过大的话,可能会阻塞其他客户端地命令。

2.bgsave

与save不同,这个命令会创建出子进程来进行生成“快照”的过程。而父进程可以继续接收到其他客户端传来的命令,互不影响。

bgsave的执行过程

1.判断当前是否存在其他正在工作的子进程,如果有,则bgsave直接返回。

2.如果没有其他子进程,则fork出一个子进程执行任务。

3.子进程负责写文件,生成“快照”,父进程继续接收其他客户端的命令。

4.子进程完成持久化的操作后会通知父进程,并退出。

注意:

1.当在生成新的快照时,会把数据先保存在一个临时文件中,当生成完后,就删除之前的文件,将本次写完的文件的名字改成dump.rdb。实现了替换,保证了有且只有一个dump.rdb文件。

2.文件一般保存在/var/lib/redis中,当然也可以自行修改:

Redis的持久化_第1张图片

3.文件格式是二进制文件,将数据以压缩的方式写入该文件:

自动触发 

自动触发顾名思义就是系统自动进行生成快照,不需要手动操作。

在redis的配置文件中可以修改redis进行自动生成快照的频率:

Redis的持久化_第2张图片

save 900 1的意思就是900秒内修改了一次就进行保存

AOF 

可以在配置文件中手动设置AOF是否开启和设置AOF的文件名:

Redis的持久化_第3张图片

AOF的执行流程 

1.因为AOF的实时保存的,所以它需要经常与磁盘打交道,但是频繁的I/O会严重影响效率,所以AOF设计了一个缓冲区,积累一定的数据之后,再写入到磁盘。(但是期间若发生断电或者其他事故,那么数据就没了)。

2.缓冲区的刷新策略也可以由程序员自行设计:

Redis的持久化_第4张图片

需要根据不同的业务进行选择。缓冲区的刷新频率越高,那么意味着保存数据的可靠性更高,但是换来的是效率的下降。

重写机制 

为什么要进行重写?什么是重写?

Redis的持久化_第5张图片

总的来说重写就是把.aof中的文件进行了整理和修改的过程,去除了冗余并进行了合并。节省了内存也提高了将数据从磁盘读到内存的效率。

重写的流程 

1.创建出子进程,子进程进行重写,父进程继续接收客户端的命令。

2.因为在创建子进程的时候仅仅是保存了父进程当前的数据,所以之后父进程写入的数据父进程将获取不到。所以设计了一个缓冲区,专门存放fork之后产生的数据。当子进程完成重写后,利用信号通知父进程。父进程再把缓冲区的数据写入到子进程刚刚写入的aof文件里。

混和持久化 

因为考虑到aof文件恢复到内存中的速度比较慢,所以设计出了一种混合持久化的操作。即按照AOF的方式将每条命令都记录到磁盘上,同时aof文件中存的数据的格式也是二进制格式。

可以在配置文件中开启是否进行混合持久化:

Redis的持久化_第6张图片

比较AOF和RDB 

1.RDB的文件格式是二进制格式,AOF是文本格式。

2.RDB不是实时保存,而AOF是实时保存。

3.RDB加载恢复数据的速度要大于AOF。

总结:根据不同的业务需求和场景进行选择。

 

你可能感兴趣的:(Redis,redis,数据库,缓存,后端)