Redis 作为内存数据库，持久化是保证数据不丢失的关键。它提供了两种主要方式：RDB（Redis DataBase）和 AOF（Append Only File）。两者各有优劣，适用于不同场景。
RDB：定时快照
RDB 在指定时间间隔内将内存中的数据快照写入磁盘，生成一个紧凑的二进制文件（默认 dump.rdb）。
触发方式：
- 手动执行
SAVE（阻塞）或BGSAVE（后台异步）。 - 通过配置
save <seconds> <changes>自动触发，例如save 900 1表示 900 秒内至少 1 个键被修改则触发。
优点：
- 文件紧凑，适合备份和灾难恢复。
- 恢复大数据集时速度比 AOF 快。
- 对主进程性能影响小（BGSAVE 会 fork 子进程）。
缺点：
- 两次快照之间若发生故障，会丢失最近的数据。
- fork 子进程时，如果数据量大会导致短暂阻塞。
适用场景：
- 对数据完整性要求不高，能容忍几分钟数据丢失。
- 需要定期备份，或用于灾难恢复。
- 数据集较大，且希望快速重启恢复。
AOF：实时日志
AOF 记录每个写操作命令，以追加方式写入文件（默认 appendonly.aof）。重启时通过重放命令恢复数据。
工作流程：
- 命令追加到
aof_buf。 - 根据
appendfsync策略同步到磁盘：always：每个命令都同步，最安全但性能最差。everysec：每秒同步一次（默认），兼顾性能与安全，最多丢失 1 秒数据。no：由操作系统决定，性能最好但可能丢失较多数据。
- 随着文件增大，触发 AOF 重写（
BGREWRITEAOF）压缩体积。
优点：
- 数据安全性高，
everysec下最多丢 1 秒数据。 - 文件易于理解和解析，可手动修复。
缺点：
- 文件通常比 RDB 大，恢复速度慢。
- 高写入负载下，
always策略会显著降低性能。
适用场景：
- 对数据安全性要求高，不能容忍较多数据丢失。
- 写操作频繁，但能接受稍慢的恢复速度。
如何选择？
实际生产环境常采用混合持久化（Redis 4.0 及以上支持）。开启 aof-use-rdb-preamble yes 后，AOF 重写时先以 RDB 格式写入前半部分，再追加增量命令。这样既保证恢复速度，又降低数据丢失风险。
决策建议：
- 缓存场景：可只开 RDB，甚至关闭持久化（如果数据可重建）。
- 数据重要性高：开启 AOF（
everysec），并配合 RDB 做定期备份。 - 追求快速恢复：使用混合持久化。
注意事项：
- 持久化不能替代主从复制或集群，高可用需结合哨兵或 Cluster。
- 监控磁盘空间和 fork 耗时，避免持久化失败。
- 根据业务容忍度调整
save和appendfsync参数。
总之，没有绝对优劣，只有适合与否。理解业务对数据丢失的容忍度和性能要求，才能做出合理选择。