【Redis系列】这篇文章带你彻底搞懂Redis的持久化机制

最新推荐文章于 2024-10-09 12:19:39 发布

Data跳动

最新推荐文章于 2024-10-09 12:19:39 发布

阅读量214

点赞数

文章标签： redis 缓存数据库分布式

本文链接：https://blog.csdn.net/weixin_43958974/article/details/108876412

版权

【Redis系列】将详细剖析面试中常出现的考点内容，力求优质干货和通俗易懂，读完后，你将彻底搞懂Redis的以下几个高频面试题目。

Redis数据类型
Redis持久化机制
缓存击穿、缓存穿透和缓存雪崩等问题
Redis缓存淘汰机制
Redis集群的主从复制
Redis集群模式及工作原理

相信很多小伙伴应该知道，缓存中的数据在遇到进程退出或者服务器宕机等意外情况时将会发生丢失，而我们知道Redis对数据的操作是基于内存的，那么Redis在遇到意外时是如何恢复丢失数据的呢，这就要涉及到这篇文章所讲的内容了—Redis的持久化机制，这也是面试中最最最常问的重点。

Redis的持久化机制有两种，分别是RDB和AOF。接下来空空就给大家细聊下这两个优秀的小可爱，看看它们是怎么解决这个问题的呢？

RDB持久化 | Redis DataBase

RDB持久化是将当前Redis中全部数据生成快照保存在硬盘中，（啥是快照？）快照也就是说会把Redis所有的内存数据进行二进制序列化，然后存储到磁盘中。RDS持久化操作可以手动触发，也可以自动触发。

手动触发

一种是save命令：执行save命令会手动触发RDB持久化，但是save命令会使Redis服务处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的请求。而当Redis服务储存着大量数据时，会造成较长时间的阻塞，所以在开发中一定要谨慎使用。

在这里插入图片描述

另一种是可以触发RDB持久化的是bgsave命令，它和save最大的不同就是持久化过程不会造成Redis服务的阻塞。它是如何做到的呢？Redis进程在执行bgsave命令时，会根据需要再执行fork操作创建一个子线程，然后把快照持久化的任务就交给子进程来完成了，而Redis进程可以继续处理其他业务需求，并不会造成阻塞，哦，不对，在创建子线程的fork阶段还是会有阻塞的，不过这个情况一般时间是很短的。没读懂没关系，看图！

在这里插入图片描述

自动触发

除了执行以上命令手动触发之外，Redis内部还可以自动触发RDB持久化。在自动触发的RDB持久化都是采用bgsave的方式，减少Redis进程的阻塞时间。那么都是在什么场景下，才会自动触发呢？

在配置文件中设置了save的相关配置，如save m n, 它表示在m秒内数据被修改过n次时，就会自动触发bgsave操作。
当从节点做全量复制时，主节点会自动执行bgsave操作，并且把生成的RDB文件发送给从节点。
执行debug reload命令时，也会自动触发bgsave操作。
执行shutdown命令时，如果没有开启AOF持久化也会自动触发bgsave操作。

介绍完了RDB持久化以及触发方式，小伙们已经知道了RDB持久化就是定期不定期地把缓存数据进行快照存储，即使遇到宕机等意外也可以从磁盘中恢复。而且RDB是二进制压缩文件，格式紧凑，非常适合用在数据传输、全量复制和灾难恢复等场景下。

文章开头我们就说了Redis的持久化机制有两种，分别是RDB和AOF，既然RDB小可爱如此优秀，那么还有AOF什么事呢？

其实RDB也没那么优秀啦。我们再来回顾下RDB的两个触发命令，save会使RDB服务进入阻塞状态，而bgsave虽然大大减少了阻塞时间，但学过操作系统的小伙伴们肯定知道fork操作创建子进程是属于重量级的，执行成本太高，无法做到实时持久化，或者秒级持久化。

而接下来要介绍的AOF，恰正能解决数据持久化的实时性，而且也是目前主流Redis持久化的方式。那么它是如何做到的呢？AOF持久化是把每次的写命令都追加到写入日志中，当需要恢复数据时重新执行AOF文件里的命令即可。这里插一句，类似的应用还很多，比如分布式文件HDFS的NameNode中就有编辑日志edits,还有列式存储数据库HBase中的预写入日志，如果有小伙伴们对这些分布式文件系统感兴趣的可以留言,后续来几篇大数据技术栈系列的讲解。

回来，继续讲我们的AOF，关于它的持久化流程，先上个图，大家对它的基本流程现有个印象，等会我们再细聊每一个环节。

在这里插入图片描述

首先所有的写命令的操作都会先追加到AOF缓存区（aof_buf）中，然后再从AOF缓存区中同步到AOF文件里，那么文件是如何同步的呢？有以下三种策略：

Always：每次写入缓存区都要同步到AOF文件中，这种策略最安全，但效率也是最慢；
No：每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件的周期不确定，而且增大了每次同步的硬盘的数据量；
Everysec：每次写入缓冲区后，由专门的线程每秒钟同步一次，做到兼顾性能和数据安全。这个也是默认策略。

但是也有这么个问题，随着服务器运行时间的增加，被保存执行的写命令越来越多，AOF文件的体积也会越来越大，就会导致占用过多的服务器磁盘空间，而且进行数据还原时所需要的时间也会更长。为了解决这个问题，就需要对AOF进行重写来减小AOF文件的体积。

什么是重写呢？就是服务器会创建一个体积小很多的新的AOF文件来替代现有的AOF文件。那么这个新的AOF文件又是怎么来的呢？其实是通过读取服务器当前的数据库数据，然后用新的命令去代替原有的多条命令的方式，来减少原来AOF文件中冗余的命令。比如说，有100条写命令，每次将1个数据存放到list中，那么原AOF文件中就会有100条写命令的记录，而新的AOF文件中会用一条写命令，将100个数据一次存入list中，来代替原来的100条记录，进而减少了很多AOF文件的体积。

还有就是什么时候会进行文件重写？
两种方式，第一种就是手动触发，直接使用使用bgrewriteaof命令进行。
另一种是自动触发，这里先介绍两个参数分别为 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage。自动触发是通过这两个参数的配置来确定自动触发的时机，其中auto-aof-rewrite-min-size表示运行AOF重写时文件大小的最小值，默认为64MB；auto-aof-rewrite-percentage表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认为100。只有两者同时超过时才会自动触发文件重写。