企业官网建设流程全解析

1. 引言：Redis 是内存数据库，数据会丢吗？

Redis 被称为“内存数据库”，很多初学者都会有疑问：

Redis 重启后，数据还在吗？

答案是：
👉取决于你是否开启了持久化，以及使用哪种方式。

Redis 提供了两种核心持久化机制：

• RDB（Redis DataBase）快照
• AOF（Append Only File）日志

它们分别从性能和数据安全两个方向解决问题。

2. RDB：定期快照式持久化

2.1 什么是 RDB

RDB 的核心思想是：

在某一时刻，把 Redis 内存中的数据完整地保存为一个快照文件。

生成的文件通常是：

dump.rdb

2.2 RDB 的触发方式

RDB 可以通过多种方式触发：

自动触发（配置）

save 900 1 save 300 10 save 60 10000

含义：

• 900 秒内有 1 次写 → 生成快照
• 300 秒内有 10 次写
• 60 秒内有 10000 次写

手动触发

SAVE# 阻塞BGSAVE# 后台（推荐）

2.3 RDB 的工作原理

1. Redis 主进程fork子进程
2. 子进程将内存数据写入.rdb文件
3. 主进程继续处理请求（COW 机制）

2.4 RDB 的优点

• 文件紧凑，体积小
• 恢复速度快
• 对 Redis 性能影响较小
• 适合备份、迁移

2.5 RDB 的缺点

• 可能丢失最近一段时间的数据
• 大数据量下 fork 有开销
• 不适合高频数据变更场景

3. AOF：追加日志式持久化

3.1 什么是 AOF

AOF 的核心思想是：

把每一次写命令，按顺序追加到日志文件中。

文件通常是：

appendonly.aof

AOF 持久化功能的实现可以简单分为 5 步：

1. 命令追加（append）：所有的写命令会追加到 AOF 缓冲区中。
2. 文件写入（write）：将 AOF 缓冲区的数据写入到 AOF 文件中。注意！！！此时并没有同步到磁盘。
3. 文件同步（fsync）<font style="color:rgb(60, 60, 67);">fsync</font>将阻塞直到写入磁盘完成后返回，保证了数据持久化。
4. 文件重写（rewrite）：随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
5. 重启加载（load）：当 Redis 重启时，可以加载 AOF 文件进行数据恢复。

3.2 AOF 的开启方式

appendonly yes

3.3 AOF 写入策略（fsync）

appendfsync always appendfsync everysec appendfsync no

3.4 AOF 重写（Rewrite）

随着时间推移，AOF 会越来越大，因此 Redis 提供AOF 重写机制：

用最少的命令，重建当前数据状态。

触发方式：

• 自动（配置）
• 手动：BGREWRITEAOF

3.5 AOF 的优点

• 数据安全性高
• 丢失数据少
• 可读性好（文本命令）

3.6 AOF 的缺点

• 文件体积大
• 恢复速度慢
• 写入频繁，对磁盘依赖高

4. RDB vs AOF：核心对比

5. 同时开启 RDB + AOF

Redis支持两者同时开启：

save ... appendonly yes

启动时：

• 优先使用AOF 恢复数据
• RDB 作为备份手段

👉这是生产环境的推荐方案。

6. 生产环境配置建议

通用建议

• AOF 使用everysec
• 开启 RDB 作为兜底
• 合理配置重写阈值

auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

7. 一个常见误区

AOF 一定比 RDB 安全。

实际上：

• appendfsync no风险很高
• 任何机制都存在极端丢失场景

8. 总结

Redis 的持久化，本质是性能与数据安全的权衡：

• RDB：快照，快、轻，但可能丢数据
• AOF：日志，安全，但慢、占空间

参考

Redis持久化机制详解

文中图片来自《Redis开发与运维》