企业官网建设流程全解析

线上 Redis 实例要配持久化，很多人的做法是照着默认redis.conf抄一遍，或者干脆把save全注释掉只留 AOF。真出事那天才发现，Redis 持久化机制这套东西从来不是“开不开”的问题，而是“你愿意为哪一种失败场景付代价”的问题。RDB、AOF、混合持久化三条路，丢数据的边界、阻塞主线程的时机、吃掉的磁盘和内存完全不一样，所谓策略选择方案，本质是把业务能接受的损失量化出来，再反推配置和硬件。这篇东西写给正在给一套 Redis 定持久化方案的人，也写给那些线上已经跑着、但说不清自己到底能丢多少数据的人。下面这些参数、估算方式和踩坑记录，都是能在真实环境里复现的，不是文档搬运。

1. 三种持久化形态守住的边界完全不同

先把概念掰开。很多人把 RDB 和 AOF 当成“两种备份方式”，选一个就行，这个理解一开始就偏了。它们保护的是不同维度的东西：RDB 保护的是“某个时刻的完整状态”，AOF 保护的是“从某个时刻到现在的操作序列”。前者像月底的资产快照，后者像银行流水。快照丢了可以补打，流水断了就再也拼不回去。混合持久化更特殊，它压根不是一种新的数据安全手段，而是把“恢复速度”这件事单独拎出来优化。

1.1 RDB 的本质是一次 fork 出来的时间点快照

bgsave触发后，Redis 主进程 fork 出一个子进程，子进程继承父进程的整个内存页表，然后在子进程里把当前内存状态序列化成二进制文件写盘，父进程继续处理请求。这个设计的精妙之处在于子进程看到的是 fork 那一瞬间的内存视图，之后父进程怎么改都不影响它——靠的是操作系统的写时复制（copy-on-write）。

所以 RDB 文件里永远是一个“过去某一秒”的完整状态，粒度由save规则决定。默认配置在 6.2 是save 900 1 300 10 60 10000，7.0 改成了save 3600 1 300 100 60 10000，触发门槛明显放宽了。这个改动背后的逻辑很直接：RDB 的 fork 成本随实例内存增长而增长，官方不想让大实例太频繁地 fork。

RDB 的致命弱点也在这里。两次快照之间的所有写入，在进程崩溃时全部消失。60 秒规则意味着最坏情况丢 60 秒数据，但如果这一分钟写入量很低没到 10000 次，可能几个小时才存一次。你以为配置了持久化，实际丢数据的窗口远超预期。

1.2 AOF 记的是“改了什么”，不是“改成什么”

AOF 把每条写命令追加到文件末尾，恢复时从头重放一遍。这种“重放日志”的模型决定了它的丢数据边界由appendfsync决定，而不是由时间窗口决定。everysec下最坏丢 1 秒，always下理论上不丢（但性能和磁盘寿命代价极大），no下交给操作系统，通常能丢几十秒甚至更多。

AOF 的另一个特性是文件会不断膨胀。一条INCR执行一百万次就是一百万条记录，但最终状态只是一个数字。所以需要 AOF 重写（bgrewriteaof）：fork 子进程，根据当前内存状态生成一份最小命令集，替换掉旧文件。重写和 RDB 一样有 fork 成本，也一样有 COW 内存膨胀。

注意：AOF 不是“事务日志”，落盘成功不代表命令生效成功。极端情况下 AOF 里有一条LPUSH，但对应的 key 因为maxmemory淘汰策略在内存里已经不存在了，重放时行为会和你想象的不一样。过期时间相关的命令在 AOF 重放时也会被特殊处理（PEXPIREAT用绝对时间戳），这点在跨时区机器上做恢复时要留意。

1.3 混合持久化解决的是重启耗时，不是数据安全

Redis 4.0 引入aof-use-rdb-preamble yes，AOF 重写时先生成一段 RDB 格式的二进制作为文件头部，后面再追加增量 AOF 命令。加载时先快速读入 RDB 部分，再回放一小段增量。这个设计让“重启加载 10GB 数据”从几分钟压缩到几十秒。

但它不改变丢数据的边界。混合持久化下依然是appendfsync决定同步频率，依然是每秒可能丢数据。很多人误以为开了混合持久化就稳了，实际上只是重启快了，该丢的一条不少。

Redis 7.0 又往前走了一步，引入多部分 AOF（multi-part AOF）：AOF 目录下拆成base.rdb（或base.aof）加多个incr.aof，再用一个 manifest 文件记录哪些文件有效。这个改动的实际收益是彻底干掉了重写期间内存里那块巨大的 AOF 重写缓冲区——6.x 时代重写期间所有新写入都要在内存里攒一份，写入量大时能把实例直接撑爆。7.0 直接落成增量文件，内存峰值下来了。代价是备份时不能再复制单个文件，得把整个appenddirname目录一起打包。

2. fork 那一刻的真实成本：bgsave 没你想的那么轻

“bgsave 是后台执行的，不影响主线程”——这句话只对了一半。子进程确实在后台干活，但 fork 这个系统调用本身是在主线程里执行的，执行期间整个 Redis 卡住，一条命令都不处理。这个阻塞时长，是我见过最多人低估的指标。

2.1 bgsave 的时间线拆成四段看

一次完整的bgsave可以拆成四段：fork 阻塞、子进程写盘、COW 内存增长、子进程退出。四段里只有第二段是真正“不阻塞”的，其余三段都会以不同方式影响服务。

fork 阻塞时长取决于页表规模。Linux 4KB 页下，16GB 内存大约有 400 万个页表项，光复制页表就要几十毫秒起步，还要加上内核调度和内存分配的开销。实测 8GB 实例 fork 通常 40 到 80 毫秒，16GB 就可能到 100 毫秒以上，32GB 的老机器上我见过 300 毫秒的。300 毫秒意味着什么？如果 QPS 是 5 万，这期间积压 1.5 万个请求，客户端连接池会被打满，超时开始连锁扩散。

第二段写盘，影响的是磁盘 IO。如果 RDB 文件和 AOF 文件在同一块盘上，bgsave 期间的顺序写会把磁盘带宽吃满，AOF 的 fsync 被拖慢，进而引发下一节要讲的退化问题。

第三段 COW 内存增长是最容易被忽略的。fork 之后父进程每修改一个内存页，内核就要为这个页做一次复制，多占一份物理内存。写入越猛、快照持续越久，增量越大。最坏情况是内存翻倍，直接触发 OOM Killer 或者把机器拖进 swap。

2.2 copy-on-write 的内存增量怎么估

估算公式不复杂，但需要三个输入：写入速率（字节/秒）、快照持续时间（秒）、页放大系数。

COW 增量 ≈ 写入速率 × 快照持续时间 × 页放大系数

页放大系数的来源是这样的：写入是按 key 的，但 COW 是按内存页（4KB）复制的。如果你写了一百个分散的小 key，可能碰到一百个不同的页，每个页 4KB 全部复制一遍；如果写的是一百个相邻的大 key，页复用率高，放大系数接近 1。真实业务里 key 是散落的，放大系数通常在 1.5 到 3 之间，取值保守一点按 3 算。

举个具体例子。一个 16GB 数据的实例，QPS 2 万，平均写入 1KB，写入速率 20MB/s。bgsave 因为磁盘慢持续了 90 秒，期间写入 1.8GB，乘 3 倍放大，COW 增量约 5.4GB。也就是说这台 16GB 数据的机器，bgsave 期间实际需要 21GB 以上的可用内存，否则就危险了。

反推配置：如果机器是 32GB 内存、数据 16GB，看起来有一倍余量，但操作系统本身要占 2 到 3GB，客户端输出缓冲区要占一块，再叠上 5GB 的 COW，余量其实只剩下几个 GB。这也是为什么很多团队的经验值是“数据量不超过物理内存的 50%”，而不是 70%。

Redis 6.0 之后有个特别实用的字段rdb_last_cow_size和aof_last_cow_size，直接在INFO persistence里就能看到上一次 fork 实际产生了多少 COW 内存。这比任何公式都准，建议把它接进监控，观察一周峰值，再回头调整内存水位。

2.3 把 fork 耗时压下去的几个实际手段

第一个手段是控制单实例内存规模。fork 阻塞跟页表项数量正相关，把 32GB 的大实例拆成四个 8GB 的小实例，单次 fork 阻塞能降到原来的四分之一左右，代价是运维复杂度和连接数上升。分片这个决策，持久化成本应该是其中一个考量项，而不是只看内存利用率。

第二个手段是关掉透明大页（THP）。THP 会把 4KB 页合并成 2MB 页，页表项少了，fork 变快了，听起来很美。但 COW 的粒度也跟着变成 2MB——只要往一个大页里写一个字节，整个 2MB 都要复制。对于写分散的场景，COW 内存放大能到十几倍，反而更危险。Redis 官方的建议一直是关闭 THP，就是这个原因。

第三个手段是错开 fork 时间。如果同一台物理机上跑了多个 Redis 实例，并且save规则都一样，它们会在启动后相近的时间点同时触发 bgsave，磁盘和 CPU 出现周期性尖峰。把不同实例的save规则稍微错开，或者干脆用外部定时任务在低峰期统一触发，能平滑掉这个尖峰。

第四个手段是打开rdb-save-incremental-fsync yes（默认就是 yes）。它让子进程每写 32MB 就 fsync 一次，而不是写完全部再同步，避免退出时一次性刷盘造成长尾延迟。aof-rewrite-incremental-fsync yes是同样的逻辑，用在 AOF 重写上。这两个参数一般不用动，但如果你接手了一套被人改成no的配置，记得改回来。

3. appendfsync 三档之间的差别不止一个数量级

appendfsync是 AOF 里最重要的一个参数，也是被误解最多的一个。三档配置在很多教程里被简化成“性能—安全”的滑动条，实际上它们的失效模式完全不同，不是简单的线性关系。

3.1 always 与 everysec 的丢数据边界

always的语义是每条写命令执行完立即 fsync。理论上零丢失，代价是每条命令都要等一次磁盘同步，QPS 直接掉到磁盘 IOPS 的量级。普通机械盘大概几百，SSD 也就几千到几万。更要命的是写入放大和磁盘寿命，一块消费级 SSD 每天被写几十上百 TB，撑不了多久。

everysec的语义是后台线程每秒 fsync 一次。注意是“后台线程”，不是主线程做完 fsync 才返回。主线程把数据写进 AOF 缓冲区就返回，后台线程负责刷盘。所以正常情况下性能几乎等同于不持久化。丢数据的边界是：如果进程崩溃（不是机器掉电），缓冲区里的数据还在操作系统页缓存里，最多丢 1 秒；如果整机掉电，页缓存没刷盘的部分全丢，也是 1 秒左右。

no的语义是完全交给操作系统的脏页回写策略，通常 30 秒左右刷一次。这个档位在容器化环境里风险更高，因为宿主机内核参数（dirty_ratio、dirty_expire_centisecs）不完全受你控制，实际刷盘间隔可能远超预期。生产环境上除非是纯缓存，一般不建议用no。

3.2 everysec 在磁盘打满时会向 always 退化

这是最隐蔽的一个坑。everysec模式的实现里有个保护逻辑：如果距离上一次 fsync 成功已经超过 2 秒，主线程在执行写命令时会被强制阻塞，等待 fsync 完成。这是为了防止缓冲区无限增长。

触发条件就是磁盘慢。假设 bgsave 正在把磁盘带宽吃满，或者磁盘本身 IOPS 不够，或者云盘的突发额度用完了，AOF 的 fsync 开始变慢，超过 2 秒，主线程就卡住了。此时的表现是 Redis 延迟从 0.2 毫秒突然飙到几秒，但 CPU 和 QPS 看起来都正常，排查时很容易走偏到“是不是有大 key”“是不是网络抖动”。

我在一套云上实例上遇到过这个情况：白天一切正常，每天凌晨磁盘快照备份的时候，Redis 延迟就抖动。查了很久才定位到备份任务把云盘带宽吃满，AOF fsync 超时，主线程被动等待。解决办法是把 AOF 和 RDB 放到不同的云盘，或者把备份任务挪到业务低峰并且限速。

提示：INFO persistence里有个aof_delayed_fsync计数器，记录的就是“fsync 被延迟”的次数。这个值只要不是 0 且在增长，就说明磁盘跟不上，配置层面调什么参数都没用，得从硬件或者写入量入手。

3.3 重写期间的写放大与“重写追不上写入”

AOF 重写这件事，6.x 和 7.x 的实现差异非常大，需要分开说。

6.x 的重写过程是这样的：fork 子进程，子进程根据当前内存生成新 AOF 文件；同时父进程把所有新写入命令，除了写进旧的 AOF 文件，还要在内存里再攒一份到“AOF 重写缓冲区”。等子进程写完，父进程把缓冲区里的内容追加到新文件末尾，然后原子替换。

问题就在那块重写缓冲区。它是纯内存的，没有硬上限。如果重写持续 5 分钟，期间写入速率 20MB/s，缓冲区就会攒到 6GB。这 6GB 是在原有内存之上的额外开销，叠上 COW 增量，实例很容易被打穿。写入速率越高、重写越慢，这个雪球滚得越大，极端情况下重写永远追不上写入，形成“重写—缓冲区膨胀—内存不足—淘汰 key—重写再次触发”的死循环。

7.0 的多部分 AOF 把这个缓冲区彻底去掉了。重写期间新写入直接开一个新的incr.aof文件追加，不攒内存。重写完成后通过 manifest 切换有效文件列表，旧的 base 和 incr 文件择机删除。这个改动对大写入量实例的意义非常大，如果你的版本还在 6.x 并且 AOF 缓冲区被打爆过，升级到 7.x 是比调参数更有效的解法。

还有一个参数no-appendfsync-on-rewrite，默认no。设成yes时，重写期间不做 fsync，这样可以避免重写和 fsync 抢磁盘，降低主线程阻塞概率。代价是重写期间的写入完全没有落到盘上，如果这时候宕机，丢的不是 1 秒，而是整个重写期间的所有数据。这个参数本质是拿数据安全换稳定性，除非磁盘实在太差且有其他补偿手段，我一般不建议开。

4. 把参数算出来：磁盘带宽、重写阈值、内存水位的定量推演

持久化配置最容易犯的错，是靠感觉拍参数。auto-aof-rewrite-percentage 100是默认值，就抄 100；min-size 64mb是默认值，就抄 64mb。这些默认值对一个小实例完全够用，对一个几十 GB 的实例可能就是灾难。参数得算。

4.1 auto-aof-rewrite-percentage 和 min-size 的联动关系

AOF 重写的触发条件是：当前 AOF 文件大小比上次重写后的大小增长了auto-aof-rewrite-percentage百分比，并且绝对大小超过auto-aof-rewrite-min-size，两个条件同时满足才触发。

这意味着实际触发点 = max(基础大小 × (1 + percentage/100), min-size)。

假设上次重写后 AOF 是 1GB，percentage 100，min-size 64mb。增长到 2GB 触发重写，需要额外写入 1GB。如果这台实例写入速率是 20MB/s，1GB 大概 51 秒就写满了——也就是说重写每 51 秒触发一次。这显然太频繁了，fork 和磁盘开销会把实例压垮。

正确做法是把percentage调大，比如 200 到 300，让重写间隔拉长到几分钟甚至十几分钟。但也不能无限大，因为重写期间要读全部内存、写一份完整的新文件，AOF 越大重写耗时越长，重写期间的资源占用也越久。这里有个经验区间：让重写频率落在 10 分钟到 1 小时之间比较合适，具体看写入量。

还有一种情况是写入量本身很小，AOF 涨得慢，靠percentage触发要等很久，但文件里垃圾命令（被覆盖的写、已删除的 key）已经很多了。这时可以靠min-size兜底，比如设成 512MB 或 1GB，保证文件不会无节制增长。

4.2 磁盘带宽与 IOPS 的最低配置怎么倒推

先算稳态写入带宽。写入 QPS 乘以平均命令大小就是每秒要落盘的字节数。2 万 QPS、平均 1KB，就是 20MB/s，一天 1.7TB。这个数字决定了磁盘容量的下限——考虑重写需要额外一份完整文件的空间，磁盘至少要能容纳 AOF 当前大小 + 新 AOF 大小 + RDB 文件 + 一些余量。对于 20MB/s 的实例，AOF 涨到 20GB 是很平常的事，磁盘给 100GB 是底线，200GB 才安心。

再算重写期间的峰值带宽。重写要读一遍内存数据、写一份新文件，速度和磁盘顺序写带宽相关。如果磁盘顺序写能到 200MB/s，10GB 数据的重写大约 50 秒。这段时间里稳态的 20MB/s 写入还得继续，所以峰值带宽需求是 220MB/s 左右。如果磁盘总共只有 100MB/s，重写就要 100 秒以上，期间 CPU 和内存压力都翻倍。

IOPS 的需求主要来自 AOF 的 fsync。everysec下每秒一次 fsync 对 IOPS 要求不高，但每次 fsync 的延迟要稳定，云盘上常见的问题是突发额度耗尽后 IOPS 掉到基线。如果基线只有 1800 IOPS，而实例每秒有几千次小写入需要合并刷盘，fsync 延迟就会上去，进而触发 3.2 节说的退化。

提示：评估云盘不要看峰值 IOPS，要看基线 IOPS 和吞吐。很多云盘的“最高 5 万 IOPS”是靠突发额度撑起来的，持续跑十几分钟就掉到几千。AOF 是持续写入型负载，正好撞在这个陷阱上。

4.3 maxmemory 与持久化的相互挤压

maxmemory设成物理内存的多少，和持久化策略强相关。如果开了 RDB 或 AOF 重写，内存峰值 = 数据量 + COW 增量 + 客户端输出缓冲区 + 复制缓冲区（如果有从库）。

最容易被忽略的是客户端输出缓冲区。一个KEYS *或者SMEMBERS大集合，能把几 GB 数据塞进输出缓冲区。如果有从库，repl-backlog和从库的输出缓冲区又是额外开销。这些加起来，maxmemory设成物理内存的 70% 是相当激进的，50% 到 60% 更稳妥，具体看写入强度和 fork 频率。

还有一个细节：maxmemory-policy设为noeviction时，内存满了写命令直接报错。这在缓存场景下会引发业务雪崩，但在“当存储用”的场景下反而是对的——宁可报错也不能悄悄删数据。持久化方案的选择会影响这个决策：如果只靠 RDB、允许丢数据，那用allkeys-lru淘汰是合理的；如果要保证数据不丢，noeviction加上内存水位告警才配套。

5. 四套可以照着抄的配置组合

前面讲的都是零件，这一节拼成整机。四套配置对应四类典型业务，参数可以直接拿去用，但部署前务必按自己的写入量和内存规模重新算一遍 4.1 和 4.2 的数字。

5.1 纯缓存：允许全丢，但要防“假持久化”

纯缓存场景下数据可以从数据库重建，持久化的意义只剩“重启后不用全量回源，避免把数据库打穿”。这种情况下 RDB 就够了，AOF 反而是负担。

# 纯缓存，16GB 数据，32GB 内存 save 3600 1 300 100 stop-writes-on-bgsave-error no rdbcompression yes rdbchecksum yes appendonly no maxmemory 20gb maxmemory-policy allkeys-lru

关键在stop-writes-on-bgsave-error no。这个参数默认是yes，意思是 bgsave 失败后拒绝所有写命令。设计初衷是防止“你以为在持久化其实早就失败了”，但对纯缓存来说这是灾难——磁盘满了一下，整个服务变成只读，业务直接挂。缓存场景应该关掉它，让服务继续跑，磁盘问题靠监控告警解决。

rdbcompression yes用 LZF 压缩字符串对象，能显著减小文件体积，代价是 fork 子进程多花一点 CPU。rdbchecksum yes用 CRC64 校验文件完整性，官方说有大约 10% 的性能损耗，但能防止加载到损坏的文件。这两个我一般都开着。

5.2 会话与队列：容忍秒级丢失

会话数据、轻量队列这类业务，丢几秒可以接受，但丢几分钟就要出问题。这时候 AOFeverysec是唯一选择，RDB 作为辅助。

# 会话存储，8GB 数据，16GB 内存 appendonly yes appendfsync everysec aof-use-rdb-preamble yes auto-aof-rewrite-percentage 200 auto-aof-rewrite-min-size 512mb no-appendfsync-on-rewrite no aof-load-truncated yes save 3600 1 300 100 stop-writes-on-bgsave-error yes

aof-use-rdb-preamble yes是混合持久化开关，重启时先加载 RDB 部分再回放增量，8GB 数据从几分钟降到几十秒。aof-load-truncated yes允许加载被截断的 AOF 尾部——机器突然断电时 AOF 最后一条命令可能只写了一半，设成yes会打印警告并加载到截断点为止，设成no则直接启动失败。生产环境基本都是yes，但要配合告警，因为截断意味着确实丢了数据。

保留 RDB 的作用是双保险：AOF 文件如果因为某些极端原因损坏、无法加载，还能退回上一个 RDB 快照，损失一部分而不是全部。这也是一种“离线备份”思路，把 RDB 文件定期同步到对象存储，能防住误删、磁盘损坏这类事故。

5.3 准存储：一条都不能丢的代价

订单、账务这类场景，Redis 通常只做缓存层，真正的持久化在数据库。但如果确实要用 Redis 承担一部分准存储职责，配置就得往安全侧压。

# 准存储，4GB 数据，16GB 内存（留足 COW 空间） appendonly yes appendfsync always aof-use-rdb-preamble yes auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 256mb no-appendfsync-on-rewrite no stop-writes-on-bgsave-error yes maxmemory-policy noeviction

appendfsync always的代价必须提前算清楚。假设写入 QPS 5000，每次 fsync 需要 0.2 毫秒，理论上磁盘能扛住，但实际因为排队和抖动，延迟会明显上升。上这套配置之前一定要压测，把 P99 延迟和磁盘 util 都看一遍。如果 QPS 上万，always基本不可行，得换思路——比如业务侧做双写，Redis 只做加速层。

maxmemory-policy noeviction配合always，意思是宁可写失败也不丢数据。这时候内存水位告警必须做，而且要提前，因为一旦打满就是硬失败，不会自动淘汰。

另外这类场景应该考虑主从加哨兵或者集群，单机再稳也有硬件故障。持久化解决的是“进程崩溃和重启”的问题，解决不了“机器没了”的问题，这两件事经常被混为一谈。

5.4 从库持久化：一个被低估的坑

“主库不开持久化，从库开持久化，性能和安全兼得”——这个方案流传很广，但它有个致命的失效场景。

主库不持久化，重启后内存是空的。从库此时还连着（或者重连），发现主库的复制 ID 变了，触发全量同步，主库生成一份空的 RDB 发给从库，从库的数据被清空。整个过程非常快，等你反应过来，从库也没数据了。这个坑我在两套环境里都见过，出事时大家的反应都是“从库不是有 AOF 吗”——有，但被全量同步覆盖了。

正确的做法是：主库至少要保留 RDB，保证重启后能恢复到接近最新的状态；或者用哨兵/集群的故障转移机制，在主库重启前先把从库提升为主。单纯靠“从库持久化”来兜底，只在这两种情况下成立：主库重启时手动阻止从库同步，或者主库重启后立刻从备份恢复数据再让从库连。

从库持久化的配置本身和主库一样，但要额外注意repl-diskless-sync和repl-diskless-load。无盘复制省掉了主库落盘 RDB 的步骤，全量同步更快，但如果从库配置了repl-diskless-load swapdb，加载期间内存会翻倍，小内存机器要小心。

6. 上线之后怎么验证：指标、演练和一次真实排查

配置写完只是开始。持久化这种东西，平时看不出问题，出事时才发现配置错了，那时候已经晚了。必须有一套持续验证的机制。

6.1 每周都要扫一眼的六个字段

INFO persistence里有几十个字段，真正需要盯的就那么几个。

latest_fork_usec这个指标特别值得单独建一个告警。它直接反映主线程被阻塞的时长，超过 100 毫秒就应该介入，超过 500 毫秒基本可以确定线上已经在丢请求了。查它的命令很简单：

redis-cli info stats | grep latest_fork_usec redis-cli info persistence | grep -E "cow_size|fork|rewrite"

rdb_changes_since_last_save是另一个容易被忽略的。如果这个数字一直在涨，说明 save 规则一直没触发，实际丢数据窗口比你以为的长得多。纯缓存场景下这个值大点无所谓，准存储场景下它应该被控制在可接受范围内。

6.2 一次“重启后少了两小时数据”的完整排查链路

说一个具体的排查过程。某团队反馈：实例重启后，业务数据回退到了两小时前的状态，但配置里明明开了 AOF。

第一步看配置是否真的生效。CONFIG GET appendonly返回no。到这里基本就明白了——配置文件里写了appendonly yes，但那次是手工启动的实例，加载的不是那份配置文件，或者配置文件被覆盖了。这种情况在有多个启动脚本、容器编排和手工运维混用的环境里特别常见。

第二步确认历史。INFO persistence里aof_enabled:0，rdb_last_save_time换算出来正好是两小时前。结合save规则是3600 1，说明这两小时里写入次数没到 1 次触发条件，所以一直没有新的 RDB。

第三步复盘为什么没被发现。监控里只配了“进程存活”和“内存使用”，没配持久化相关指标。rdb_changes_since_last_save一直在涨，但没人看。

第四步定改进方案。一是配置管理收口，所有实例的redis.conf由配置中心统一下发，启动脚本强制指定配置文件路径，启动后用CONFIG GET做一次校验。二是监控加上aof_enabled、rdb_changes_since_last_save、rdb_last_bgsave_status三个指标，并设置阈值告警。三是每次变更后做一次“杀进程重启”演练，验证数据真的能恢复。

这个案例里最有价值的教训不是“要开 AOF”，而是“配置的存在不等于配置的生效”。任何持久化相关的变更，都必须用实际重启来验证，看日志里的DB loaded from append only file或者DB loaded from disk才算数。

6.3 一份可执行的持久化演练清单

最后给一份可以直接落地的演练清单，建议每季度跑一次，尤其是版本升级、硬件迁移、参数调整之后。

1. 在预发环境准备一份和线上同规格的实例，灌入接近真实规模的数据（至少 50% 内存占用）。
2. 用redis-benchmark或者业务回放工具持续压测，记录基线延迟和 QPS。
3. 手动执行BGSAVE，观察latest_fork_usec、rdb_last_cow_size和压测延迟的抖动幅度。
4. 手动执行BGREWRITEAOF，观察重写耗时、内存峰值、aof_delayed_fsync是否有增长。
5. 用kill -9杀掉进程模拟崩溃，重启后比对数据，确认丢失量在业务可接受范围内。
6. 断掉磁盘（云盘上可以卸载再挂载），观察aof_last_write_status变 err 后的行为，确认stop-writes-on-bgsave-error的设置符合预期。
7. 如果是主从架构，杀掉主库并在从库有数据的情况下重启，确认不会发生“从库被空数据覆盖”。
8. 把演练结果记录成表格，作为下次容量规划的输入。

演练里第 5 步和第 7 步是最容易暴露问题的。很多人做了几年 Redis 运维，从来没真正杀过进程验证恢复，全靠“应该没问题”的心理预期。真出事那天，这个预期是要还的。

我个人在实际操作中的体会是，持久化方案讨论到最后，往往不是技术选型问题，而是“业务能不能说清楚自己能丢多少”。能让业务方明确回答“丢 1 秒可以，丢 5 秒不行”的团队，配置一般都配得不差；回答“最好都别丢”的，通常最后配了个默认值，然后在某次故障里被动接受了那个默认值带来的损失。把这句话问清楚，比调十个参数都有用。