Redis 持久化机制

1. 为什么需要持久化

Redis 是内存数据库，进程重启或服务器宕机后内存数据会全部丢失。持久化机制将内存数据写入磁盘，保证重启后数据可恢复。

Redis 提供两种持久化方式，通常混合使用：

方式	原理	文件	数据完整性	恢复速度
RDB	定时全量快照	`dump.rdb`	可能丢失最后一次快照后的数据	快 ✅
AOF	记录每条写命令	`appendonly.aof`	最多丢失 1 秒数据	慢（文件大）
混合持久化	RDB + AOF 结合	`appendonly.aof`	接近 AOF，恢复更快	中等 ✅

2. RDB（Redis Database）

2.1. 原理

RDB 在指定时间间隔内，对内存数据做全量快照，将某一时刻的数据集序列化保存到磁盘。

触发快照时：
主进程 ──fork──▶ 子进程（Copy-On-Write）
                    │
                    └──▶ 将内存数据写入临时 .rdb 文件
                                    │
                                    └──▶ 替换旧的 dump.rdb
主进程继续处理请求（不阻塞）

Copy-On-Write（写时复制）：fork 后父子进程共享内存页，只有当父进程修改某页数据时才复制该页，最大程度减少内存占用。

2.2. 触发方式

自动触发（配置文件）：

# redis.conf 默认配置
save 3600 1      # 3600 秒内有 1 次写操作则触发
save 300  100    # 300 秒内有 100 次写操作则触发
save 60   10000  # 60 秒内有 10000 次写操作则触发

手动触发：

SAVE      # 同步快照，阻塞主线程（生产禁用）
BGSAVE    # 后台异步快照，fork 子进程执行，推荐
BGSAVE SCHEDULE  # 如果已有 BGSAVE 在执行则跳过

2.3. 配置

save 900 1
save 300 10
save 60 10000

dbfilename dump.rdb         # RDB 文件名
dir /var/lib/redis          # 文件保存路径
rdbcompression yes          # 是否压缩（LZF 压缩，推荐开启）
rdbchecksum yes             # 是否校验数据完整性（CRC64）

2.4. 优缺点

优点：

二进制紧凑格式，文件小，恢复速度快
fork 后主进程不阻塞，对性能影响小
适合备份和灾难恢复（每小时/每天备份 .rdb 文件）

缺点：

两次快照之间的数据可能丢失（取决于 save 策略）
fork 本身会短暂阻塞，数据量大时 fork 耗时较长

3. AOF（Append Only File）

3.1. 原理

AOF 将每一条写命令以文本形式追加到 AOF 文件，重启时重放所有命令来恢复数据。

写命令执行流程：

Client ──▶ 执行命令 ──▶ 命令写入 AOF 缓冲区 ──▶（按策略）──▶ 刷盘

AOF 文件内容示例：
*3
$3
SET
$5
hello
$5
Redis

3.2. 刷盘策略

appendfsync always      # 每次写命令后立即 fsync：数据最安全，性能最低
appendfsync everysec    # 每秒 fsync 一次：最多丢失 1 秒数据，推荐 ✅
appendfsync no          # 由操作系统决定何时 fsync：性能最好，可能丢较多数据

三种策略对比：

策略	数据安全性	写入性能	推荐场景
`always`	最高（不丢数据）	最低	金融核心数据
`everysec`	高（最多丢 1 秒）	高 ✅	绝大多数生产场景
`no`	低	最高	允许较多数据丢失

3.3. AOF 重写（Rewrite）

随着运行时间增长，AOF 文件会越来越大（包含大量冗余命令）。AOF 重写对文件进行压缩，只保留当前数据的最小命令集：

重写前（冗余命令多）：
SET counter 1
SET counter 2
SET counter 3
...
SET counter 100

重写后（只保留最终状态）：
SET counter 100

# redis.conf 自动重写触发条件
auto-aof-rewrite-percentage 100   # 文件体积比上次重写后增长 100% 时触发
auto-aof-rewrite-min-size 64mb    # 文件达到 64MB 时触发（两个条件同时满足）

BGREWRITEAOF   # 手动触发 AOF 重写（后台执行，不阻塞主线程）

3.4. 优缺点

优点：

数据安全性高，everysec 最多丢失 1 秒数据
文件可读，便于人工排查和恢复

缺点：

文件体积比 RDB 大得多
恢复速度慢（需重放所有命令）
always 模式对性能影响较大

4. 混合持久化（推荐）

Redis 4.0+ 引入混合持久化，综合 RDB 恢复快 + AOF 数据完整两者的优点。

4.1. 原理

AOF 重写时，将当前内存状态以 RDB 格式写入 AOF 文件头部，后续增量写命令以 AOF 格式追加：

AOF 文件结构（混合模式）：
┌───────────────────────────────────────────┐
│  RDB 二进制数据（重写时刻的全量快照）         │
│──────────────────────────────────────────│
│  SET key1 val1                            │  ← 重写后的增量 AOF 命令
│  INCR counter                             │
│  ...                                      │
└───────────────────────────────────────────┘

恢复时：先加载 RDB 部分（快），再重放增量 AOF 命令（少），兼顾速度和完整性。

4.2. 配置

appendonly yes               # 开启 AOF
aof-use-rdb-preamble yes     # 开启混合持久化（默认 yes，Redis 7.0+）
appendfsync everysec         # 刷盘策略

5. 持久化方案选型

数据丢失容忍度？
      │
      ├── 完全不能丢 ──▶ AOF（appendfsync = always）+ 主从复制
      │
      ├── 允许丢 1 秒 ──▶ 混合持久化（RDB + AOF everysec）推荐 ✅
      │
      └── 允许丢几分钟 ──▶ 仅 RDB（简单，恢复快）

场景	推荐方案
纯缓存（丢了可重建）	关闭持久化，性能最优
一般业务	混合持久化（AOF everysec + RDB）
金融/支付核心数据	AOF always + 主从复制
定期冷备份	RDB（定时 BGSAVE，拷贝 .rdb 到备份存储）

appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
save 3600 1
save 300 100

混合持久化 + RDB 兜底，兼顾数据安全与恢复速度，适合绝大多数生产场景。