Redis 持久化是指将内存中的数据保存到磁盘上，确保在 Redis 服务重启或服务器故障后数据不会丢失。Redis 提供了两种主要的持久化机制：

? 一、RDB（Redis Database）

核心机制：在指定时间间隔生成数据集的时间点快照（Snapshot）。

工作方式：

1. 手动触发：执行 SAVE（阻塞主线程）或 BGSAVE（后台异步保存）。
2. 自动触发：配置 save <seconds> <changes>（例如 save 900 1 表示 900 秒内有至少 1 次修改则触发）。
3. 过程：
   • Fork 子进程处理写入。
   • 子进程将内存数据压缩写入临时 RDB 文件。
   • 替换旧的 RDB 文件（默认 dump.rdb）。

优点： ✅ 文件紧凑（二进制压缩），节省磁盘空间
✅ 恢复速度快（直接载入到内存）
✅ 对性能影响小（子进程处理）

缺点： ❌ 可能丢失最后一次快照后的数据（取决于配置间隔）
❌ 数据集大时，fork() 可能阻塞主线程（尤其在虚拟机环境中）

? 二、AOF（Append Only File）

核心机制：记录每次写操作命令（写后日志），重启时重新执行命令恢复数据。

工作方式：

1. 配置 appendonly yes 开启 AOF。
2. 命令写入内存缓冲区，按策略同步到磁盘：
   • appendfsync always：每个命令同步（数据强一致，性能低⚠️）
   • appendfsync everysec：每秒同步（平衡方案，默认推荐⭐）
   • appendfsync no：由操作系统决定（可能丢失较多数据）
3. AOF 重写（Rewrite）：
   • 压缩日志（移除冗余命令），触发方式：
     • BGREWRITEAOF 手动触发。
     • 配置 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 自动触发。

优点： ✅ 数据安全度高（最多丢失 1 秒数据）
✅ 可读性好（文本格式记录命令）
✅ 后台重写不影响主线程

缺点： ❌ 文件体积通常比 RDB 大
❌ 恢复速度较慢（需重放命令）
❌ 高负载时 everysec 可能轻微延迟

? 三、混合持久化（RDB + AOF）

Redis 4.0+ 支持：结合两者优势，重启时更快恢复。

原理：

1. 开启 AOF（appendonly yes）。
2. 设置 aof-use-rdb-preamble yes。
3. 重写时：将当前数据以 RDB 格式写入 AOF 文件头部，后续命令以 AOF 格式追加。

效果：

• 恢复速度接近 RDB ⚡️
• 数据安全性等同 AOF ?

? 方案选择建议

️ 注意事项

1. 监控磁盘空间：AOF 文件可能快速增长。
2. 禁用 SAVE 命令：生产环境用 BGSAVE 避免阻塞。
3. 备份策略：无论用哪种，定期将 RDB/AOF 文件复制到异地。
4. 测试恢复流程：备份文件必须能成功加载！

? 最佳实践：生产环境通常启用混合持久化，同时配置 RDB 定时备份（如每天）到独立存储，实现多层次数据保护。

如果需要进一步优化细节（如重写阈值、fsync 调优），可结合业务负载具体调整参数！