丢多少，算能接受
先泼一盆冷水：纯缓存场景，Redis 丢了数据也不算事故——穿透、击穿、雪崩三篇的防线全在，缓存没了大不了回源重建。持久化真正护航的是那些「丢不得」的用法：分布式锁的状态、幂等标记、计数器、以及干脆把 Redis 当存储用的系统。所以持久化的选型不是「要不要」，而是「重启时能接受丢多少、恢复要等多久」——这两个变量，把答案收敛到 RDB 与 AOF 的组合上。
RDB：定时快照
RDB 的思路是定期给全量数据拍快照：执行 bgsave（或按 save 规则自动触发）时，主进程 fork 一个子进程，子进程遍历内存把数据写成紧凑的二进制文件，主进程照常服务。快照期间数据还在被修改怎么办？靠 写时复制（Copy-On-Write）：fork 后父子进程共享同一份物理内存，只有被写到的页才复制一份新页——子进程看到的是拍快照那一刻的静止世界，主进程的新修改不影响它。
RDB 的优点直白：文件紧凑、恢复快（直接载入二进制）；缺点同样直白：两次快照之间的数据全丢——5 分钟一拍，最多丢 5 分钟。还有个隐藏的坑：fork 本身有瞬时成本，实例越大 fork 越慢（几十 GB 的实例要几百毫秒，单线程被卡住），写时复制在写流量大时还会让内存用量冲高——这就是淘汰策略篇说 maxmemory 只设七成的来由之一。
AOF：逐条日志
AOF 换了个思路：不拍快照，把每条写命令追加到日志文件里，恢复时从头重放。丢多少取决于什么时候刷盘，由 appendfsync 决定：always 每条命令都刷，基本不丢但性能腰斩；everysec 每秒刷一次，最多丢一秒，是默认也是黄金平衡点；no 交给操作系统，性能最好、丢失窗口不可控。
逐条追加的代价是日志膨胀——同一个 key 改一百遍就记一百条。AOF 的自我救赎是重写：bgrewriteaof 起一个子进程，按当前内存里的最终状态生成一份等价的最小命令集（key 改一百遍只记最终值），旧日志整体作废。重写同样走 fork 加写时复制，同样有大实例的瞬时成本。
混合持久化：缝起来的答案
RDB 恢复快丢得多，AOF 丢得少恢复慢——4.0 的 aof-use-rdb-preamble（混合持久化）把两者缝在一起：AOF 重写时先写一段 RDB 格式的全量数据打底，之后的增量写命令继续以 AOF 格式追加。恢复时先快速载入 RDB 段，再重放尾部少量增量——恢复速度向 RDB 看齐，丢失窗口向 everysec 看齐，默认开启，没有明显短板。
怎么选
一条主线收束所有场景：纯缓存，RDB 定时快照足够，丢了就重建，还省性能；承载状态，混合持久化加 everysec 是标准答案；不当存储用就别被「持久化」三个字迷惑——Redis 的持久化是尽力而为的保险，不是数据库级别的事务承诺，真正贵重的数据请落到 DB。持久化解决「重启不丢光」，但机器本身挂了呢？主从加哨兵的自动故障转移，下一讲展开。
评论 (0)