Redis持久化AOF与RDB全面解析（大厂面试必问，看完之后offer直接到手，你学废了吗？）

最新推荐文章于 2024-07-29 14:48:28 发布

李子捌

最新推荐文章于 2024-07-29 14:48:28 发布

阅读量1.8k

点赞数 25

分类专栏：《Redis从入门到精通》系列文章标签： redis java 后端运维

本文链接：https://blog.csdn.net/qq_41125219/article/details/118740888

版权

本文详细介绍了Redis的两种持久化机制：RDB（内存快照）和AOF（增量日志）。RDB适合全量备份，恢复速度快，但可能丢失部分数据；AOF则能记录所有写操作，数据更完整，但文件较大，恢复较慢。Redis还支持混合持久化，结合RDB和AOF的优点。文中还涵盖了触发规则、配置、文件备份和修复功能等。

摘要由CSDN通过智能技术生成

1、简介

Redis的非常快，很大一部分原因是因为Redis的数据存储在内存中，既然在内存中，那么当服务器宕机或者断电的时候，数据就会全部丢失了，所以Redis提供了两种机制来保证Redis数据不会因为故障而全部丢失，这种机制称为Redis的持久化机制。
Redis的持久化机制有两种：

RDB(Redis Data Base) 内存快照
AOF(Append Only File) 增量日志

**RDB(Redis DataBase) **指的是在指定的时间间隔内将内存中的数据集快照写入磁盘，RDB是内存快照（内存数据的二进制序列化形式）的方式持久化，每次都是从Redis中生成一个快照进行数据的全量备份。
优点：

存储紧凑，节省内存空间
恢复速度非常快
适合全量备份、全量复制的场景，经常用于灾难恢复（对数据的完整性和一致性要求相对较低的场合）

缺点：

容易丢失数据，容易丢失两次快照之间Redis服务器中变化的数据。
RDB通过fork子进程对内存快照进行全量备份，是一个重量级操作，频繁执行成本高。
fork子进程，虽然共享内存，但是如果备份时内存被修改，最大可能膨胀到2倍大小。

AOF(Append Only File)是把所有对内存进行修改的指令（写操作）以独立日志文件的方式进行记录，重启时通过执行AOF文件中的Redis命令来恢复数据。AOF能够解决数据持久化实时性问题，是现在Redis持久化机制中主流的持久化方案（后续会谈到4.0以后的混合持久化）。
优点：

数据的备份更加完整，丢失数据的概率更低，适合对数据完整性要求高的场景
日志文件可读，AOF可操作性更强，可通过操作日志文件进行修复

缺点：

AOF日志记录在长期运行中逐渐庞大，恢复起来非常耗时，需要定期对AOF日志进行瘦身处理（后续详述）
恢复备份速度比较慢
同步写操作频繁会带来性能压力

官网地址

http://www.redis.io

2、RDB

2.1 简介

RDB持久化方案进行备份时，Redis会单独fork一个子进程来进行持久化，会将数据写入一个临时文件中，持久化完成后替换旧的RDB文件。在整个持久化过程中，主进程（为客户端提供服务的进程）不参与IO操作，这样能确保Redis服务的高性能，RDB持久化机制适合对数据完整性要求不高但追求高效恢复的使用场景。
下面展示RDB持久化流程：

Redis-RDB流程.png

2.2 Fork

上面说到了RDB持久化过程中，主进程会fork一个子进程来负责RDB的备份，这里简单介绍一下fork

Linux操作系统中的程序，fork会产生一个和父进程完全相同的子进程。子进程与父进程所有的数据均一致，但是子进程是一个全新的进程，与原进程是父子进程关系
出于效率考虑，Linux操作系统中使用COW(Copy On Write)写时复制机制，fork子进程一般情况下与父进程共同使用一段物理内存，只有在进程空间中的内存发生修改时，内存空间才会复制一份出来。

在Redis中，RDB持久化就是充分的利用了这项技术，Redis在持久化时调用glibc函数fork一个子进程，全权负责持久化工作，这样父进程仍然能继续给客户端提供服务。fork的子进程初始时与父进程（Redis的主进程）共享同一块内存；当持久化过程中，客户端的请求对内存中的数据进行修改，此时就会通过COW机制对数据段页面进行分离，也就是复制一块内存出来给主进程去修改。

cow示意图 (1).png