Redis被视为内存数据库，所有键值默认保存在物理内存中，读写速度极快，但一旦进程退出、机器断电或发生重启，内存中的数据就会彻底消失。持久化的核心目标是在“性能”和“数据安全”之间找到平衡，让Redis在重启后能恢复指定时间点的数据。RDB和AOF是Redis内置的两种持久化方式，它们的设计思路完全不同：前者保存某个时刻的数据快照，后者记录每一次写命令。理解它们的实现机制和差异，是配置高可用Redis的前提。
一、RDB快照持久化：原理与触发方式
RDB（Redis DataBase）持久化会在某个时间点生成数据集的时间点快照，并将该快照写入磁盘上的二进制文件，默认文件名为 dump.rdb。它并不是实时保存每一条写入，而是按照配置的触发条件执行一次全量快照。触发条件可通过 redis.conf 中的 save 指令设置，例如：
save 900 1 save 300 10 save 60 10000
上述配置表示：900秒内至少发生1次写操作、300秒内至少发生10次写操作、60秒内至少发生10000次写操作时，Redis会自动触发一次RDB快照。除了自动触发，管理员还可以通过执行 SAVE 或 BGSAVE 命令手动触发。SAVE 会阻塞Redis主进程，直到快照生成完毕，在生产环境中通常避免使用；BGSAVE 会fork一个子进程来负责将数据写入磁盘，父进程继续处理客户端请求。
RDB的核心是操作系统的写时复制（Copy On Write）机制。执行BGSAVE时，Redis主进程通过 fork 创建子进程，子进程和父进程在一开始共享同一块物理内存页。当父进程需要修改某个键时，操作系统会先将对应的内存页复制一份，再在副本上修改，因此子进程读取到的数据始终是fork那一刻的稳定快照。RDB文件的写入由子进程完成后原子地替换旧文件，不会出现半写入的中间状态。
RDB也有几个明显不足。首先，两次快照之间的写入无法被记录，一旦Redis异常崩溃，最近一次快照之后的所有修改都会丢失。其次，当数据量很大时，fork子进程本身可能耗时，且在写时复制过程中如果父进程写入密集，会消耗额外内存和CPU。不过，RDB文件是紧凑的二进制格式，加载恢复速度远快于逐条回放命令，适合做冷备份、灾备恢复和数据迁移。
二、AOF持久化：日志记录与重写机制
AOF（Append Only File）以独立日志的形式记录Redis收到的每一条写命令，默认文件名为 appendonly.aof。开启AOF后，Redis会在每次写操作执行成功后，把对应的命令追加到AOF缓冲区，再根据刷盘策略写入磁盘。配置项 appendfsync 决定了数据从缓冲区到磁盘的同步时机：
appendonly yes appendfilename "appendonly.aof" appendfsync everysec
appendfsync 有三个可选值：always 表示每次写命令都同步刷盘，数据最安全但性能最差；everysec 表示每秒同步一次，最多可能丢失一秒内的写入，性能与安全较均衡；no 表示交由操作系统决定刷盘时机，性能最好但崩溃时可能丢失较多数据。大多数生产环境选择 everysec。
随着写命令不断追加，AOF文件会越来越大，其中可能包含大量对同一个键的重复修改。为了控制文件体积，Redis提供AOF重写机制。重写不是对旧AOF文件做简单压缩，而是根据当前内存中的数据状态，生成一份新的AOF文件，只保留恢复当前数据所需的最小命令集合。例如，某个列表键先后执行了6次 LPUSH，重写后可能只保留一条包含所有元素的 RPUSH 或等价命令。Redis通过 BGREWRITEAOF 在后台完成重写，同样利用fork子进程和写时复制避免阻塞主进程。
AOF的优点在于数据完整性更高。即便使用 everysec，通常也只会丢失不超过1秒的写入，配置为 always 时几乎可以做到逐条不丢。AOF采用文本协议保存命令，可读性较好，必要时可以人工检查或修复；由于记录的是写操作日志，即使Redis进程崩溃，只要文件本身没有物理损坏，恢复时只需按顺序回放命令即可。缺点是AOF体积通常比RDB大，恢复速度慢，尤其在写入频繁、重写不及时的情况下，启动加载时间会明显增加。
三、RDB与AOF多维对比
二者的差异可以从数据安全性、恢复速度、文件体积、写入性能和对系统资源的影响几个维度来分析。RDB在数据安全性上相对较弱，默认快照策略可能丢失几分钟甚至更长时间的数据；但恢复速度非常快，适合对恢复时间要求高、能容忍一定数据丢失的场景。AOF则相反，数据安全性高，但文件大、恢复慢，适合不能接受明显数据丢失的场景。
从写入性能看，RDB的自动快照频率通常较低，对日常写入影响较小，但在 BGSAVE fork阶段和写时复制密集时可能出现毛刺。AOF根据 appendfsync 策略持续刷盘，always 模式下每次写入都要等待磁盘同步，吞吐量会显著下降；everysec 模式使用后台线程每秒刷盘，性能接近RDB，但数据安全性仍然高于RDB。
文件体积方面，RDB是二进制压缩快照，相同数据集通常比AOF小很多。AOF记录的是可读命令，虽然经过重写可以减小体积，但通常还是大于RDB。恢复时RDB只需加载快照并解析二进制结构，速度通常高于AOF逐条回放。可以通过如下命令查看Redis当前的持久化状态：
127.0.0.1:6379> INFO Persistence # Persistence loading:0 rdb_changes_since_last_save:0 rdb_bgsave_in_progress:0 rdb_last_save_time:1720000000 aof_enabled:1 aof_rewrite_in_progress:0 aof_last_bgrewrite_status:ok
上述输出中 aof_enabled:1 表示AOF已开启，rdb_bgsave_in_progress:0 表示当前没有进行RDB后台保存。了解这些状态字段有助于判断持久化是否按预期工作。
四、混合持久化与生产选型建议
Redis从4.0开始支持混合持久化，通过在AOF重写时先写入一份RDB快照作为文件开头，再把重写过程中新增的写命令追加为AOF格式。这样最终生成的AOF文件前半部分是紧凑的RDB数据，后半部分是增量命令，既保留了AOF的数据安全性，又提升了恢复速度。开启方式为：
aof-use-rdb-preamble yes
启用混合持久化后，BGREWRITEAOF生成的新AOF文件不再全是纯命令，而是RDB头加AOF尾。恢复时Redis先加载RDB部分，再回放后续命令，速度比纯AOF快，同时不会像纯RDB那样丢失较长时间的数据。对于大多数生产系统，推荐同时开启RDB和AOF，并配置 appendfsync everysec 与混合持久化。这样RDB可作为定期冷备，AOF负责保障最近写入，启动恢复时Redis优先使用AOF，因为AOF通常更完整。
选型时可按业务场景划分。如果Redis仅作为缓存，允许从数据库重建，可以只开RDB甚至关闭持久化以降低复杂度；如果存储会话、限流计数等允许少量丢失的数据，RDB加 everysec 的AOF已经足够；如果保存订单状态、库存扣减等关键业务数据，应启用AOF并选择 always 或至少 everysec，同时配置自动重写防止文件膨胀。对于数据量达到数十GB的实例，需要关注 fork 延迟，建议预留足够内存，并尽量在低峰期触发 BGSAVE 或 BGREWRITEAOF。
最后还要注意持久化文件的备份与恢复验证。无论选择哪种机制，都应定期将 dump.rdb 或 appendonly.aof 复制到其他存储介质，并在测试环境演练恢复流程。恢复Redis时，将备份文件放回配置的 dir 目录，启动Redis即可自动加载。若需导入到运行中的实例，可借助 DEBUG RELOAD 或重启服务完成。对比RDB与AOF的本质，RDB关注“某一时刻的状态”，AOF关注“每一次变化过程”，二者结合能构建更可靠的持久化方案。
Redis持久化机制RDBAOF修改时间：2026-08-23 11:11:32