Redis核心原理底层机制——持久化【RDB与AOF】

持久化

引言
[第一部分：RDB（Redis DataBase）------定期快照](#第一部分：RDB（Redis DataBase）——定期快照)
[第二部分：AOF（Append Only File）------实时记录](#第二部分：AOF（Append Only File）——实时记录)
第三部分：RDB+AOF------混合持久化
- 相辅相成
- 优势
[对比：RDB vs AOF vs 混合模式](#对比：RDB vs AOF vs 混合模式)
场景应用选择
结尾

引言

首先，我们要知道MySQL是把数据存到硬盘里的，这样的话可以保持数据长久存在，但是如果用户量过于庞大呢？数据库每次取数据都要从硬盘里读出，哪怕用到了索引，但是万一第一次没有命中呢？然后数据库不负众望的崩了，用户感到一直在卡卡卡...

你一拍大腿，说，不可以就这样结束！

于是你学到了有一种内存数据库叫Redis，Redis则把数据存到内存里，当新数据数据库里没有的时候，他会把新数据保存并给MySQL写入，当遇到数据库里有的数据，他会保存到内存里，下次再读这个数据直接从内存读就好了，这样的话大批数据想要读数据就都要经过Redis中间层~

速度是大大提升了，但是你又发现存在内存里，那一断电不就数据全无，在读数据的时候不又得从MySQL里读吗？这样的话不就又回到了原点吗？

这个时候就要提到我们今天所讲的持久化机制了------RDB与AOF

（RDB定时存储，AOF实时存储）

话不多说，我们开始正题！

第一部分：RDB（Redis DataBase）------定期快照

咱们先来聊聊RDB，它的全名是Redis DataBase。你可以把它理解成给Redis内存里的数据拍了一张"全家福"（快照）。咔嚓一下，某一时刻所有的数据都被定格下来，存到硬盘里去了。（说白了就是定期备份）

SAVE与BGSAVE

阻塞式拍摄（SAVE）：我们都知道Redis最大的特点是单线程，那他拍摄快照的时候，后面过来要读数据等一些列的请求就不管了，那岂不是把Redis最受欢迎的特点'快'给干掉了，这不纯纯自杀行为么，所以这个时候我们有了下面所说的BGSAVE
无感式拍摄（BGSAVE）：既然自己干会卡住，那咋办？Redis作者其实已经想到了，Redis可以通过系统调用fork()，瞬间克隆出一个子进程。这个子进程长得和他一模一样，拥有他那一刻的所有内存数据。子进程负责在后台默默把数据写入硬盘，而Redis（父进程）继续处理读写请求。

如果在拍照过程中数据被修改了怎么办？

这里要介绍操作系统的一项关键技术------写时复制（Copy-On-Write）机制。

当开始拍照时，子进程（替身）和父进程（Redis主进程）共享同一份内存数据。如果有数据被修改，系统会将被修改的数据单独复制一份给主进程使用，而子进程仍保留修改前的原始数据。这样就能确保快照拍摄的是特定时刻的完整数据状态，既保证了数据一致性，又实现了高效处理。

自动触发

你可能会问，难道我要一直手动执行命令吗？当然不用，你可以给它定闹钟。

在配置文件里，你可以写上类似这样的规则：

"900秒内，如果至少有1次写操作，就拍一张。"
"60秒内，如果至少有10000次写操作，就拍一张。"

这就叫自动触发。只要满足了这些条件，后台的那个子进程就会自动跳出来工作，完全不用你操心。

优缺点

优点：

恢复贼快：因为RDB是一个紧凑的二进制文件，恢复数据的时候，直接把整个文件加载进内存就行，速度飞快。
备份方便：只有一个文件，你想备份就拷走，想恢复就放回来，简单粗暴。

缺点：

可能会丢数据：因为它是定时拍的，假设你设了5分钟拍一次，结果第3分钟的时候断电了。那这3分钟内新增或修改的数据，就随着内存烟消云散了。
偶尔卡顿：虽然平时不卡，但如果数据量特别巨大（比如几十GB），找替身（fork子进程）的那一瞬间，还是会有短暂的停顿，虽然很短，但对超高并发的系统来说，这也是个隐患。

总的来说，RDB适合用来做灾难恢复和快速重启，但如果你要求每一笔数据都不能丢，光靠它可能还不够稳。

第二部分：AOF（Append Only File）------实时记录

RDB拍摄快照，而AOF则是一位勤勉的记账员，它的核心功能则是：

将Redis执行的所有写操作以日志形式逐条记录。

无论执行新增、删除还是修改操作，只要数据发生变动，AOF就会在文件末尾追加一条记录。这种机制确保了即使遭遇断电等意外情况，Redis重启时只需重新执行（重放）这些操作日志，数据就能完整恢复。

同步策略

记账的频率决定了你的数据安不安全，也决定了性能高不高。Redis给了你三档选择：

同步持久化（always）：
- 特点：严格实时写入。每当有新数据产生，系统会立即将其写入硬盘，确保每条数据都完整保存。
- 优势：数据安全性最高，确保零丢失。
- 不足：由于需要等待每次写入完成，系统整体性能会受到影响。
异步持久化（everysec）：
- 特点：采用缓冲区机制。系统先将数据暂存于内存缓冲区，然后每秒自动同步一次到硬盘。
- 优势：在性能和数据安全间取得平衡，是推荐使用的模式。即使发生断电，最多只会丢失1秒内的未同步数据。
- 不足：极短时间内可能存在少量数据丢失风险。
无持久化（no）：
- 特点：完全依赖操作系统。数据仅保存在内存缓冲区，由操作系统决定何时写入硬盘。
- 优势：性能最佳，读写速度最快。
- 不足：数据安全性最低，断电时可能丢失较多未保存的数据。

AOF重写

你可能会疑惑：这种流水账记录方式过于冗长，占用空间太大！

例如，当你对一个Key执行1万次INCR操作，从1递增到10000时，AOF会记录1万条操作日志。但实际上，数据恢复时只需要知道"这个Key的最终值是10000"就足够了。

为了解决账本无限膨胀的问题，AOF提供了**瘦身（重写）**功能。

当账本文件达到一定规模时，Redis会启动一个子进程（相当于分身），读取当前数据库中Key的最新值，然后生成最精简的命令（比如直接用SET key 10000）来替代之前的上万条冗余记录。这个过程就是AOF重写（Rewrite）。

更巧妙的是：在子进程执行瘦身操作时，主进程仍在持续记录新的操作日志。当子进程完成新账本（精简版）的写入后，Redis会无缝切换新旧账本。这样既实现了账本瘦身，又确保了操作记录的完整性。

优缺点

优点：

数据安全 ：配合everysec策略，顶多丢1秒数据，比RDB那个5分钟拍一次的靠谱多了。
可读性强 ：AOF文件其实就是文本，如果你不小心误删了数据（比如执行了FLUSHALL），只要在重写发生前，把AOF文件里最后这条命令删掉，重启Redis，数据就能救回来！这叫"人工回滚"。

缺点：

恢复慢：重启时得一条条重放命令，数据量大了比RDB那个"直接加载快照"慢得多。
文件大：虽然重写了，但总体上AOF文件还是比RDB那个二进制快照要大。
IO压力：频繁地写硬盘（fsync），对磁盘性能是个考验。

总的来说，AOF就像是一个严谨的审计员，虽然话多、恢复慢，但胜在事无巨细、有据可查。

第三部分：RDB+AOF------混合持久化

既然咱们把RDB和AOF都看透了，你肯定在想：能不能来个"集大成者"？既想要RDB那种秒级恢复的速度，又想要AOF那种几乎不丢数据的安全性。

必须能！ 这就是Redis 4.0之后推出的混合持久化（Hybrid Persistence） 。这就好比给那个记流水账的AOF先生配了一台高速复印机（RDB快照）。

相辅相成

开启混合持久化后，AOF的工作模式将转变为**"总分式"结构**：

总述部分：首先以RDB的二进制快照形式，将当前内存中的所有数据完整记录在AOF文件开头
分述部分：随后新产生的写操作会继续以AOF原有的文本命令格式追加到文件末尾

这种设计既保留了RDB的高效存储特性，又延续了AOF的增量记录优势。

优势

想象一下，服务器崩了重启：

Redis先读取AOF文件开头的RDB快照部分。这部分是二进制的，加载速度极快，瞬间内存里就有了绝大部分数据。
然后，Redis再把AOF文件末尾那一点点增量的命令重放一下，补全最后几秒的变化。

结果就是：

恢复速度：几乎等同于RDB，秒级复活。
数据安全：几乎等同于AOF，只可能丢最后那一丢丢还没来得及记录的增量数据。

对比：RDB vs AOF vs 混合模式

为了让你看得更清楚，咱们直接上对比表：

维度	RDB（快照）	AOF（流水账）	混合持久化（推荐）
核心逻辑	定时拍照，存结果	一直记账，存过程	先存快照，再记增量
恢复速度	(极快)	(慢)	(极快)
数据安全	(可能丢几分钟)	(最多丢1秒)	(极高)
文件大小	小 (二进制压缩)	大 (文本日志)	中等
适用场景	备份、灾难恢复	数据库日志、高安全要求	现代生产环境首选

场景应用选择

如果你只是把Redis当"纯缓存"用 ：
- 比如存个session、页面缓存，丢了也没事，MySQL里还能查回来。
- 策略：关闭持久化，或者只开RDB。追求极致的性能，别让硬盘拖后腿。
如果你把Redis当"数据库"用 ：
- 比如存用户的余额、积分、订单状态，丢了数据可是要背锅的。
- 策略：开启AOF，并开启混合持久化。
- 配置建议：appendonly yes，appendfsync everysec，aof-use-rdb-preamble yes。
关于启动恢复的"潜规则" ：
- 这里有个坑要注意：如果Redis重启时，发现AOF文件存在，它会优先使用AOF来恢复数据，而忽略RDB文件。
- 为什么？因为AOF记录的操作更全，数据更完整。所以，生产环境通常建议RDB和AOF一起开：RDB用来做定期备份（比如每天备份一次），AOF用来做故障恢复。

结尾

Redis凭借RDB和AOF两种持久化机制，既保持了内存操作的高性能，又确保了数据的持久可靠性，这正是其成为互联网基础设施标配的关键所在。