详解Redis持久化：RDB、AOF与混合持久化

本文为个人总结，如有错误请评论区指出

文章目录

• 什么是Redis持久化
• 持久化方式
• • [RDB（Redis Database）](#RDB（Redis Database）)
  • • 触发方式
    • RDB的优缺点
  • [AOF （Append Only File）](#AOF （Append Only File）)
  • • 触发方式
    • AOF重写
    • AOF的优缺点
  • 混合持久化
  • • 触发方式
  • RDB和AOF对比
• 持久化恢复数据的流程

什么是Redis持久化

Redis是内存数据库，所有数据默认都存在内存 中，如果服务器宕机或重启 ，内存数据会全部丢失。持久化就是Redis把内存中的数据保存到硬盘的机制，目的是重启后能恢复数据，保证数据的持久性

Redis的持久化方式：RDB、AOF、混合持久化（RDB+AOF）

持久化方式

RDB（Redis Database）

RDB是快照式 持久化：在指定的时间间隔内，把redis内存中的所有数据 生成一个二进制快照文件（默认文件名dump.rdb）保存到硬盘

触发方式

• 手动触发：

  • save：同步执行，会阻塞redis主线程，直到rdb文件生成完成（生产环境禁止使用，会导致redis无法响应请求）
  • bgsave：异步执行，redis会fork一个子线程来生成rdb文件，主线程继续处理请求（生产环境推荐）

• 自动触发： 通过配置文件redis.conf中的规则触发

  例如

# 900秒内至少1个key被修改，触发bgsave
save 900 1
# 300秒内至少10个key被修改，触发bgsave
save 300 10
# 60秒内至少10000个key被修改，触发bgsave
save 60 10000

注：redis正常关闭（shutdown 命令）、主从复制时主节点也会自动触发 bgsave

RDB的优缺点

优点：

• 快照文件体积小，恢复速度极快（直接加载二进制文件到内存）
• 对主线程影响小（bgsave异步）
• 适合做冷备份、灾备（复制RDB文件即可）
  冷备份：也叫离线备份，指的是在数据库或服务停止运行、不接收任何读写请求的状态下，对数据文件进行完整拷贝
  灾备：全程是灾难恢复，指的是当系统发生重大故障（如机房断电、服务器毁坏等）时，能够快速恢复服务和数据的整套方案

缺点：

• 数据安全性低：如果触发快照后宕机，中间修改的数据会丢失
• fork的子进程会消耗内存，数据量大时可能短暂阻塞
• 不适合实时持久化场景

AOF （Append Only File）

AOF是日志式 持久化：把redis执行过的所有写命令 以文本形式追加到AOF文件（默认appendonly.aof）中

触发方式

通过配置文件redis.conf中的规则触发

# 开启 AOF（默认关闭，需要手动改为 yes）
appendonly yes

# AOF 文件名称
appendfilename "appendonly.aof"

# 同步策略（核心）
# appendfsync always ：每次写命令都同步到硬盘（最安全，性能最差）
# appendfsync everysec ：每秒同步一次（默认，兼顾性能和安全）
# appendfsync no ：由操作系统决定何时同步（性能最好，数据丢失风险最高）
appendfsync everysec

# AOF 文件重写（解决文件过大问题）
# 自动重写触发条件：当前AOF文件大小是上次重写后大小的100%，且文件大小超过64mb。两个条件必须同时满足
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF重写

AOF 会不断追加命令，文件会越来越大（比如多次修改同一个 key，会记录所有修改命令）。重写 是 Redis 会生成一个精简版的 AOF 文件：只保留恢复当前数据所需的最少命令（比如把多次修改同一个 key 的命令合并为一个）。

• 手动触发： bgrewriteaof（异步执行，不阻塞主线程）
• 自动触发： 由上面的auto-aof-rewrite-*配置决定

AOF的优缺点

优点：

• 数据安全性高：默认每秒同步，最多丢失1秒数据
• 日志文件可读性高（文本格式），可手动修复错误
• 重写机制可优化文件大小

缺点：

• AOF文件体积比RDB大，恢复速度比RDB慢
• 写操作会有额外的IO开销（追加命令），性能略低于RDB
• 极端情况下可能出现AOF文件损坏，需要修复

混合持久化

混合持久化结合了RBD和AOF的优点：

• 重写AOF文件时，先把当前内存数据生成RDB快照（二进制）写入AOF文件开头
• 之后的写命令以AOF格式追加到文件末尾
• 恢复时：先加载RDB部分（快速恢复大部分数据），再执行AOF部分（恢复最新的少量数据）

触发方式

通过配置文件redis.conf中的规则触发

# 开启混合持久化（默认开启）
aof-use-rdb-preamble yes

RDB和AOF对比

维度	RDB	AOF
数据完整性	低（会丢失最后一次快照后的所有数据）	高（最多丢失1秒的数据）
文件大小	小（二进制压缩）	大（文本命令）
恢复速度	快	慢
性能影响	小（仅fork时短暂阻塞）	大（每秒追加、同步命令）
可读性	差（二进制）	好（文本命令）

持久化恢复数据的流程

Redis 启动时，恢复数据的优先级：

1. 如果开启了 AOF，优先加载 AOF 文件恢复数据（因为 AOF 数据更全）；
2. 如果 AOF 关闭、文件损坏，才加载 RDB 文件恢复；
3. 如果两者都没有，Redis 启动后为空库