在 Redis 持久化方案选择上，建议同时开启 RDB 和 AOF，而不是二选一。原因在于，RDB 采用定时快照机制，天然存在数据丢失时间窗口，例如默认情况下可能带来约 15 分钟的数据风险，并且对误删除这类场景也无能为力；AOF 虽然记录更细，但单独使用时容易出现文件损坏、恢复耗时长、文件持续膨胀等问题，整体风险同样不低。采用混合持久化模式后，可在 AOF 文件开头写入 RDB 快照，再追加后续增量命令，从而在 Redis 数据恢复速度与数据安全性之间取得更好的平衡。
Redis 持久化最佳实践是同时启用 RDB 和 AOF，不能只选择其中一种。 仅使用 RDB 容易造成数据丢失，只使用 AOF 又可能面临文件损坏、恢复缓慢等问题。目前更推荐、也更符合生产环境实际部署经验的方案，是让 RDB 与 AOF 共存，并各自承担不同职责。
为什么不能只开 RDB？
RDB 的本质是按固定时间点生成数据快照，这也决定了它存在一个非常现实的短板：两次快照之间产生的写入数据，一旦 Redis 宕机或服务器异常退出，就可能来不及持久化保存。以默认配置 sa ve 900 1 为例，它表示 15 分钟内只要至少发生 1 次修改，就执行一次保存；也就是说，在极端情况下，最多可能丢失接近 15 分钟的数据。即便把快照频率调高，例如设置 sa ve 60 10000，这个数据丢失窗口依然存在，只是缩短，并不能从根本上消除。此外，频繁 fork 子进程再加上写入大体积快照文件，不但可能影响主进程响应，还会明显增加内存占用压力。
- 触发依赖写操作次数和时间阈值，并不是实时持久化
- 快照虽然通过
bgsa ve异步执行，但在内存占用较大时，fork 子进程仍可能发生卡顿甚至失败 - 无法处理误删场景，例如
DEL、FLUSHALL，因为快照保存的同样可能是“已经被删除”的状态
为什么不能只开 AOF？
AOF 本质上是 Redis 命令追加日志，随着系统持续运行，AOF 文件通常会不断变大，因此需要定期重写；而重写操作 bgrewriteaof 本身也会消耗较多 CPU 与磁盘 I/O。更重要的是，AOF 文件对磁盘满、异常断电、写入中断等情况较为敏感，一旦损坏，可能造成整个日志文件无法正常加载。
appendfsync always数据安全性最高，但性能损耗过大，线上环境几乎不会这样配置appendfsync everysec是较常见的折中方案，但依然存在最多 1 秒的数据丢失风险- AOF 损坏后通常需要借助
redis-check-aof修复，若修复不成功，就只能丢弃部分数据或退回使用 RDB - Redis 重启时需要顺序重放 AOF 中的每条命令，1GB 左右的 AOF 文件加载时间可能达到数分钟
怎么配 RDB + AOF 混合模式？
从 Redis 4.0 开始，官方支持混合持久化模式，也就是让 AOF 文件前半部分采用 RDB 快照格式，后续再追加增量写命令。这样做既能减少 AOF 体积，也能显著提升 Redis 重启恢复速度。不过要注意，混合持久化并不是替代 RDB 与 AOF 双重持久化策略，而是对 AOF 文件结构进行优化。
- 开启 AOF：
appendonly yes，同时建议设置appendfsync everysec - 继续保留 RDB 触发规则，例如
sa ve 300 10，用于生成额外的冷备份快照 - 打开混合持久化：
aof-use-rdb-preamble yes - 确保
dir目录磁盘空间充足，同时appendfilename与dbfilename不要冲突
Redis 启动时会优先尝试加载 AOF；如果 AOF 文件不存在或已经损坏，则会自动回退到最新的 dump.rdb；只有当两者都不可用时，才会真正发生明显的数据丢失。
容易被忽略的细节
很多人认为只要开启 AOF，Redis 数据安全就万无一失了，但实际运维中更容易被忽略的是 stop-writes-on-bgsa ve-error 和 stop-writes-on-bgrewriteaof-error 这两个配置是否保持为 yes。当后台持久化任务失败时，例如最常见的磁盘空间写满，Redis 会立即拒绝新的写入请求，随后业务层面也会快速出现报错。这并不是 Redis 的异常行为，而是它刻意设计的保护机制。真正需要重点关注的是，如果缺少完善的监控、日志和告警体系，这类问题往往不会在第一时间暴露，反而可能在后台持续累积，最终影响线上服务稳定性。
