Redis持久化策略：RDB快照与AOF日志

最新推荐文章于 2025-06-18 14:58:58 发布

J_Silver

最新推荐文章于 2025-06-18 14:58:58 发布

阅读量822

点赞数 19

CC 4.0 BY-SA版权

文章标签： redis 数据库缓存

本文链接：https://blog.youkuaiyun.com/yeliuhuo/article/details/142789589

在高性能、低延迟的分布式缓存系统中，数据的持久化是一个不可忽视的重要问题。Redis 作为一款广泛使用的内存数据库，默认情况下将所有数据存储在内存中，这使得其具备了极快的读写速度。然而，当服务器重启、宕机或意外退出时，如果没有持久化机制的支持，内存中的数据将会全部丢失。因此，Redis 提供了两种主要的持久化策略来保证数据的安全性和完整性，分别是 RDB（Redis Database Backup）快照和 AOF（Append-Only File）日志。其中，RDB 持久化策略通过周期性地将 Redis 数据集的完整副本（即快照）保存到磁盘上，可以快速恢复数据，并在一定程度上平衡了性能与持久化之间的关系。

一、RDB持久化模式

Redis服务器每隔一段时间将RDB快照数据写入本地磁盘，如果因为服务器宕机导致数据丢失，只需要将保存在本地RDB快照数据恢复到Redis即可。

但由于RDB快照的持久化策略是一种全量备份，会将系统的全部数据（包括所有文件、数据库记录、配置等）在设定的时间点进行完整的备份操作。这样的过程无疑是耗时且有一定服务器开销的，那么在备份的过程中，如何确定最终保存下来的RDB文件状态是整个过程的开始、结尾还是期间的某一时刻？针对以上问题Redis提供了两种解决方案。

RDB保存方式

1.save

在该保存模式下，Redis直接在主线程中保存，会使Redis服务完全阻塞，将读写求情都会在save操作完成前阻塞。

2.bgsave

在后台执行，将当前内存数据通过子进程异步保存到磁盘上。会 fork 出一个子进程，子进程负责将内存数据写入磁盘。由于子进程执行，主进程可以继续处理客户端请求，因此只在 fork 时可能会短暂阻塞主线程，是一种多路复用机制。

RDB自动保存

Redis 的 RDB 自动保存是基于配置文件中的save参数来进行触发的。通过save参数，可以设置当 Redis 在指定时间段内发生了某个数量的写操作时，自动触发bgsave命令生成快照文件，并将数据保存到磁盘上。

RDB优点

全量备份，备份内容完整，适合将数据在非活跃状态（即系统关闭或不提供服务时）进行备份。

灾备简单，服务恢复时只需要重新将RDB内容恢复即可。

父子进程相互隔离，异步处理高效。

RDB缺点

突发故障会丢失数据，因为是定时每隔一段时间才进行保存，在间隔期间故障会导致数据丢失。

子进程会造成额外的内存开销。

全量实时备份的适用场景小。

二、AOF持久化模式

Redis服务器在该持久化模式下通过日志形式对数据进行保存，对日志的修改不同于RDB的完整保存修改，AOF下的日志是通过追加的方式实现的（append追加）。在恢复AOF数据时，从头到尾读取执行每一条命令。一般Redis服务器恢复数据时，先是恢复AOF保存的数据，AOF出现问题时再选用RDB模式。

AOF引发的相关问题

AOF的日志追加，每次追加命令也许不会太多，但随着时间的延长，AOF文件也会十分庞大，但是也不并担心AOF过于笨重以至于大于磁盘的空间，Redis内部有一些压缩算法能对这个问题进行一定的解决。即使存在一个十分庞大的T级别AOF文件，也不必担心内存溢出，因为实际的有效命令在读取执行的过程中也不会太多，但是整个恢复过程可能会持续很长时间，会有一天到一周不等。

AOF的一些参数配置

＃ AOF 默认关闭，yes可以开启
appendonly no
# AOF 的文件名
appendfilename "appendonly.aof"
# no：不同步
# everysec：每秒备份，推荐使用
# always：每次操作都会备份，安全并且数据完整，但是慢性能差
appendfsync everysec

# 重写的时候是否要同步，no可以保证数据安全
no-appendfsync-on-rewrite no
# 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb
＃当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb