当前位置：首页 > 问答 > 正文

化紧跟时代步伐，聊聊Redis缓存持久化那些事儿和实现方法

邝冷亦
问答
2025-12-31 03:48:35
3

知乎专栏《技术夜谈》）

咱们今天就来唠唠Redis缓存持久化这个事儿，现在技术发展这么快，数据可是应用的命根子，万一服务器突然宕机或者重启，内存里的数据要是全丢了，那简直就是一场灾难，Redis提供的持久化功能，就像是给数据上了个“双保险”,至关重要。

为啥非得持久化？内存里的数据太“娇气”

Redis最厉害的地方就是快，因为它把数据都放在内存里操作，但内存有个天生的缺点：一断电，数据就没了，这就像你用电脑写文档，只在内存里编辑却不保存到硬盘，突然停电，辛苦半天全白费。（来源：Redis官方文档对持久化必要性的阐述）我们需要一种机制，能把内存里这些“活蹦乱跳”的数据，变成硬盘上“踏踏实实”的文件，这样即使Redis服务重启，也能从文件里把数据恢复回来,保证数据的持久性。

Redis的两大“法宝”：RDB和AOF

Redis主要给了我们两种方法来办成这件事，它们各有各的招,也各有各的短处。

RDB（快照方式）：拍张“全家福”

（来源：《Redis设计与实现》一书）

你可以把RDB想象成给当前数据库的数据拍一张完整的“快照”，在某个时间点，Redis会把内存中所有数据生成一个压缩过的二进制文件（默认叫dump.rdb），这个文件就像一张全家福,记录了那一刻所有数据的模样。

它是怎么实现的？
- 手动触发： 你可以在命令行里执行 SAVE 或 BGSAVE 命令。SAVE会阻塞所有请求，直到快照完成，期间Redis不能干活，所以线上环境基本不用，常用的 BGSAVE 则会后台异步进行，Redis会fork出一个子进程来专门负责写RDB文件，而主进程继续处理客户端请求,这样服务就不会中断。
- 自动触发： 在配置文件里，你可以设置规则，900秒内至少有1个key被修改”就自动触发一次BGSAVE,这样就能定期备份。
它的优点：
- 文件紧凑，恢复速度快： RDB文件是压缩的二进制格式，文件小，当Redis重启需要恢复数据时，直接把这个快照文件读入内存就行了,速度非常快。
- 适合做灾难恢复： 你可以把某个时间点的RDB文件拷贝出来，放到别的地方（比如云存储）做冷备，万一出大事,可以用它来回滚。
它的缺点：
- 可能会丢数据： 这是最大的问题，因为快照是定期拍的，如果Redis在两次快照之间宕机，那么从上一次拍快照到宕机这个时间段内写入的数据就全丢了，所以数据安全性较低。
- fork可能阻塞服务： 虽然BGSAVE是异步的，但fork子进程这个过程本身，在数据量非常大时，可能会瞬间占用较多CPU和内存,导致服务有短暂的停顿。

AOF（日志方式：）记“流水账”

（来源：Redis作者Salvatore Sanfilippo的博客文章）

AOF的思路和RDB完全不同，它不拍整体快照，而是把Redis服务器执行过的每一个写命令都记录到一个日志文件里（默认是appendonly.aof），这就像是一个超级详细的流水账本,每一步操作都记下来了。

它是怎么实现的？
- 实时记录： 当Redis执行一个写命令后,会把这个命令以协议的格式追加到AOF文件的末尾。
- 文件重写： 随着时间推移，AOF文件会越来越大，而且里面可能有很多重复或无效的操作（比如对同一个key先set后delete），所以Redis提供了BGREWRITEAOF命令，它会fork一个子进程，基于当前数据库的数据，重写一个更小的、等效的AOF文件,用这个新文件替换旧的。
它的优点：
- 数据安全性极高： 你可以配置AOF的同步策略，默认是每秒同步一次，最多丢1秒的数据，甚至可以设置成每次写命令都同步（appendfsync always），这样理论上一条数据都不会丢,但性能会下降。
- 可读性好： AOF文件是纯文本格式，里面记录的是Redis命令，万一出问题，你甚至可以用文本编辑器打开它，进行人工理解和修复（虽然一般不这么干）。
它的缺点：
- 文件通常比RDB大： 因为记录的是操作日志。
- 恢复速度慢： 重启恢复数据时，Redis需要把AOF文件里记录的命令从头到尾重新执行一遍，如果AOF文件很大,这个恢复过程会比RDB慢很多。