Redis 的持久化机制主要有以下三种方式：
1. RDB（Redis Database）
原理
RDB 是通过 快照（Snapshot） 的方式，将 Redis 内存中的数据在指定时间间隔内持久化到磁盘上，生成一个 紧凑的二进制文件（默认文件名为 dump.rdb）。
触发方式
- 手动触发：
SAVE：阻塞主线程，直到 RDB 文件生成完成（生产环境不推荐）。BGSAVE：通过fork子进程异步生成 RDB 文件，主线程继续处理请求（推荐方式）。
- 自动触发：
在redis.conf中配置save规则
优点
- 性能高：子进程处理持久化，主线程无阻塞。
- 恢复速度快：二进制文件体积小，加载效率高。
- 适合备份：单个文件便于传输和灾备。
缺点
- 数据丢失风险：两次快照间的数据可能丢失（取决于
save配置）。 - fork 开销：大数据集下
fork可能导致短暂阻塞（如 50GB 数据fork耗时约 2.5 秒）。
适用场景
- 对性能要求高，可容忍一定时间内的数据丢失。
- 需要快速恢复的场景（如全量备份）。
2. AOF（Append Only File）
原理
AOF 通过 记录所有写操作命令（如 SET, DEL 等），以日志形式追加到磁盘文件中（默认文件名为 appendonly.aof）。重启时通过重放这些命令恢复数据。
配置参数
- 同步策略（
appendfsync）：always：每次写操作立即同步到磁盘（数据零丢失，但性能较差）。everysec：每秒批量同步一次（默认值，平衡性能与安全性）。no：由操作系统决定同步时机（性能最好，但数据丢失风险高）。
- AOF 重写：
通过BGREWRITEAOF命令压缩日志文件，去除冗余命令（如重复SET key value）。
优点
- 数据安全性高：默认每秒同步，最多丢失 1 秒数据。
- 日志可读性强：AOF 文件是 Redis 协议格式，便于调试。
缺点
- 文件体积大：日志文件通常比 RDB 文件大 2-3 倍。
- 恢复速度慢：需逐条重放命令，大数据集恢复时间较长。
适用场景
- 对数据安全性要求极高的场景（如金融交易系统）。
- 需要避免数据丢失的业务（如实时订单系统）。
3. 混合持久化（RDB + AOF）
原理
Redis 4.0+ 引入 混合持久化，结合 RDB 和 AOF 的优势：
- 初始阶段：写入 RDB 格式的全量数据快照。
- 后续阶段：追加 AOF 格式的增量写操作命令。
优点
- 兼顾性能与安全性：RDB 快速加载 + AOF 精准恢复。
- 减少数据丢失：仅丢失最后一次 AOF 同步后未持久化的数据。
适用场景
- 高性能与高安全性并重的场景（如高并发电商系统）。
4. 无持久化（Non-persistence）
- 原理：关闭 RDB 和 AOF，数据仅保留在内存中。
- 适用场景：缓存场景（如临时会话存储），无需数据持久化。
如何选择持久化方式？
| 场景 | 推荐方式 | 说明 |
|---|---|---|
| 高性能优先 | RDB | 快速恢复，适合大规模数据备份。 |
| 数据安全性优先 | AOF + everysec | 最多丢失 1 秒数据，适合金融类业务。 |
| 平衡性能与安全 | 混合持久化 | Redis 4.0+ 推荐，兼顾 RDB 和 AOF 优点。 |
| 纯缓存场景 | 无持久化 | 不需要持久化，关闭 RDB/AOF。 |
总结
- RDB：适合快速恢复和全量备份，但存在数据丢失风险。
- AOF：适合高安全性场景，但性能和恢复速度略逊于 RDB。
- 混合持久化：Redis 4.0+ 的推荐方案，结合两者优势。
- 生产环境建议：根据业务需求选择 RDB/AOF 或混合持久化，避免使用
SAVE命令。
THE END
