本文教你如何在 30 分钟内为生产环境的 Redis 选择正确的持久化策略，把”机器重启数据全丢”与”AOF 写放大拖慢业务”两类典型问题一次性规避掉。读完本文你会拿到三件可直接落地的产出：第一，RDB 与 AOF 的工作机制对照表，含触发条件、磁盘开销、恢复速度三维度评估；第二，三种典型业务场景下的推荐参数模板（纯缓存、会话存储、轻量 KV 主数据）；第三，Redis 4.0 引入的混合持久化（RDB-AOF）的开启方法与回退方案。本文默认使用 Redis 7.x，参数同样适用于 Redis 6.2 LTS。
一、为什么 Redis 重启后数据可能全部消失
如何让 Redis 在进程重启或机器宕机后不丢数据，是缓存层运维要先回答的问题。Redis 默认在没有显式配置时会保留 redis.conf 里的 save 规则，但很多团队为了避免阻塞会把 save 全注释，并且不开 AOF，结果就是机器一旦重启，所有 key 直接清零。如果业务只是把 Redis 当无状态缓存，这个行为没问题；但如果你把 Session、限流计数、订单去重等业务状态也放在 Redis 上，就必须显式选一种持久化策略。
Redis 提供两种持久化机制：RDB 是定期快照（按时间或写入次数触发 fork 子进程把内存写成二进制文件），AOF 是追加日志（把每条写命令以协议格式追加到文件）。两者可以单独用，也可以一起用。如果你正在为缓存层挑选服务器，可以参考云服务器选购指南中关于内存与磁盘 IO 的部分。云服务器（即通过虚拟化技术从物理服务器集群中切分出的弹性计算资源）做 Redis 时要给 RDB 的 fork 预留至少 30% 内存余量，否则可能 OOM。
二、RDB 与 AOF 的工作机制对照
理解两种机制的本质差异，比死记硬背参数有用得多。核心区别如下：
- 触发方式：RDB 按 save 规则或 BGSAVE 命令触发；AOF 每次写命令都追加，由 appendfsync 控制何时 fsync
- 文件特点：RDB 是紧凑二进制快照，文件最小；AOF 是文本协议日志，体积通常是 RDB 的 3 到 5 倍
- 数据丢失窗口：RDB 在两次快照之间崩溃就丢失之间所有写入；AOF 按 fsync 策略可控制在 1 秒以内
- 恢复速度：RDB 读取速度最快，大数据集冷启动只要几十秒；AOF 需要逐条 replay 全部命令，可能数倍于 RDB
- 主从同步：RDB 用于全量同步初始化，AOF 不用于主从直接传输
只用 RDB 的好处是性能最好、文件最小，缺点是会丢两次快照之间的数据。只用 AOF 的好处是最多丢 1 秒数据，缺点是文件大、恢复慢。VPS（Virtual Private Server，虚拟专用服务器，通过虚拟化划分的独立实例）部署时磁盘 IOPS 是 AOF fsync 策略的关键瓶颈，要按业务的写 QPS 反推磁盘选型。具体磁盘类型评估可对照美国 VPS 部署教程里关于 SATA SSD 与 NVMe SSD 的差异部分。Hostease 的 VPS 方案默认配备 NVMe SSD，在高写入场景下能有效降低 AOF fsync 延迟。
三、三种典型场景的参数模板
按业务对数据安全的容忍度，把生产场景分成三类：
- 纯缓存（命中失败时回源数据库即可）：可以完全关闭持久化，save “” 与 appendonly no
- 会话存储（用户登录态丢失要重登，影响用户体验）：用 RDB，save 900 1、save 300 10、save 60 10000
- 轻量 KV 主数据（限流计数、订单去重等不能丢）：混合持久化，aof-use-rdb-preamble yes、appendonly yes、appendfsync everysec
appendfsync（控制 AOF 写入磁盘的时机）有三个取值：always 每条写命令都 fsync，性能最差但最安全；everysec 每秒 fsync 一次，最常用；no 完全交给操作系统，性能最好但不可控。生产环境绝大多数场景应该用 everysec。auto-aof-rewrite-percentage 与 auto-aof-rewrite-min-size 控制 AOF 重写触发，默认 100% 与 64MB 在小内存场景偏激进，1 GB 以上的实例建议把 min-size 提到 1 GB，避免重写过于频繁。
四、混合持久化与日常运维建议
Redis 4.0 引入的混合持久化（aof-use-rdb-preamble yes）把 RDB 与 AOF 的优点合在一起：AOF 文件的前半段是 RDB 二进制快照，后半段是上次重写后追加的增量命令。恢复时先快读 RDB 部分，再 replay 末尾少量命令，比纯 AOF 恢复快好几倍，同时保留了最多 1 秒数据丢失窗口的安全性。Redis 7 默认就开启混合持久化，从 Redis 6 升级时检查 redis.conf 是否带上这一行即可。
日常运维三件事建议你今天就做完：第一，确认每台 Redis 实例 redis.conf 中的持久化策略与业务对数据丢失的容忍度对齐；第二，跑一次 BGSAVE 与 BGREWRITEAOF，观察 latency 监控里是否有 fork 引起的尖峰；第三，把 RDB 快照按天异地备份到对象存储或另一台机器，避免单点磁盘损坏导致两种持久化文件同时丢失。如果你的 Redis 同时承担 WordPress 的对象缓存，可以参考WordPress 性能调优实战与WordPress 香港主机购买指南里的缓存层规划。总结来说，RDB 与 AOF 不是二选一的对立关系，而是两种互补机制，混合持久化加 everysec 是绝大多数生产场景的合理默认。可以考虑把这套策略写进上线 checklist，让每个新实例都自动符合数据安全基线。如果你需要一台磁盘 IO 稳定的服务器来运行 Redis，Hostease 的 VPS 方案支持按需升级 NVMe SSD 容量，适合从单机缓存到集群部署的多种场景。在团队推进时，建议把本文流程沉淀为一份内部 wiki 页面，新人入职第一周就完成一次完整演练，把每一步的执行命令、预期输出、异常处理都写清楚。线上变更前再过一遍前置检查清单，确认备份、回滚脚本、灰度窗口三件事都准备就绪，再开始动作。技术细节之外，运维节奏的稳定才是长期收益的来源，定期的复盘会议、变更通报、故障演练三件事缺一不可，让团队对系统的掌控感从被动等告警切换到主动看趋势。日常巡检与季度演练应该写进岗位职责，由专人负责并对结果负责，避免责任分散导致问题被反复忽略。建议你今天就把本文流程在测试环境完整跑一遍，可以考虑把每一步的命令与预期输出沉淀进运维 wiki，再推荐团队按季度做一次复盘演练，让这套优化方法在团队里形成可持续的习惯。