Redis 持久化的承诺，都是在什么条件下兑现的

Redis 的持久化常被简化为一道选择题：RDB 还是 AOF，everysec 还是 always。但把 Redis 官方文档、antirez 的旧文和社区的生产经验放在一起读，会发现这些选项背后是一组有条件的承诺：每个“保证”都绑定了一个前提，前提不成立时，承诺本身不会降级为“差一点”，而是直接失效。antirez 自己说过，Redis 的强项是数据模型，短板就是持久化[reference:0]。这句话不是谦虚，而是一份边界声明。

fork：快照的“瞬时”是页表层面的瞬时

RDB 快照和 AOF 重写都依赖 fork() 创建子进程。宣传中的印象是“fork 很快，阻塞只在毫秒级”。这个印象有一半是对的，但漏掉了两个关键条件。

fork() 本身不复制内存，只复制页表，所以“不复制数据”是真的[reference:1]。但页表复制本身需要时间，而且这个时间随数据集大小增长。实际观察到的阻塞从几毫秒到数百毫秒不等，取决于内存容量和页表规模。对于一个标称亚毫秒延迟的存储系统，几百毫秒的停顿不是“短暂抖动”，而是一次可感知的可用性中断。

更微妙的是 copy-on-write 的代价不在 fork 那一刻支付，而在 fork 之后的写入路径上逐渐兑现。子进程与父进程共享物理页；父进程一旦写入某个页，内核就必须为该页创建副本。在 fork 之后的高写入负载下，COW 可以让实际内存占用翻倍，最坏情况下达到原数据集的两倍。这意味着“fork 不复制内存”这个事实，并不能推导出“fork 不会导致内存压力”。承诺的条件是：fork 之后没有密集写入。写入越频繁，COW 的隐性成本越接近一次真实的全量复制。

THP（透明大页）会把这个边界推得更远。一个 2 MB 的大页中只要有一个字节被修改，整个 2 MB 页都要复制，COW 放大倍数从 4 KB 粒度直接跳到 2 MB 粒度。在开启 THP 的机器上，fork 的内存风暴可以从 2 倍膨胀到 4 倍甚至更高[reference:5]。Redis 文档对此的建议是关闭 THP，但这是一个部署层面的条件，而不是持久化机制自己能控制的变量。

everysec：一秒的窗口，前提是 fsync 跟得上

appendfsync everysec 被几乎所有生产指南推荐为默认选择，理由是“最多丢失 1 秒数据”且性能开销很小（约 1–2%）[reference:6]。这个数字本身是准确的，但它绑定了一个容易被忽略的前提：fsync 在后台以秒为节奏稳定完成。

everysec 的实现方式是：写命令先追加到 AOF 缓冲区，由一个后台任务每秒执行一次 fsync。如果在两次 fsync 之间进程崩溃，缓冲区中尚未刷盘的数据就会丢失，上限大约是一秒的写入量[reference:7]。这是设计上公开接受的代价，不是缺陷。

问题出现在磁盘延迟不稳定的场景。如果单次 fsync 因为存储抖动耗时超过一秒，后台 fsync 任务就会落后；Redis 在主线程中检测到这种情况时，可以选择阻塞等待 fsync 完成，以避免缓冲区无限增长。此时“everysec 不阻塞主线程”的承诺就被打破了：不是每一条命令都等待磁盘，但当磁盘慢到一定程度时，写入路径会被间接拖住。承诺的兑现条件从“每秒一次 fsync”滑向了“fsync 的尾延迟必须可控”，而后者是存储硬件和内核 I/O 调度器的问题，不是 Redis 配置能完全决定的。

always：把持久化承诺直接押在 IOPS 上

appendfsync always 提供最强的持久性保证：每条写命令在返回客户端之前等待 fsync 完成，最多丢失一条命令。但这条承诺的性质和前两者不同：它把 Redis 的写入吞吐上限直接绑定到了底层存储的随机写 IOPS 上。

在机械盘上，随机写 IOPS 约 150；SATA SSD 约 3000；NVMe 可以高得多[reference:9]。这意味着 always 模式下的吞吐天花板不是 Redis 的处理能力，而是磁盘每秒钟能完成多少次持久化确认。单次 fsync 在 SSD 上约 0.2–1 ms，但在高并发下排队会让 P99 延迟跳到 20–50 ms，QPS 被压到 IOPS 上限[reference:10]。Redis 官方文档对 always 的警告是：性能代价“可能是灾难性的”，因为 Redis 是单线程的，fsync 直接在事件循环中执行[reference:11]。

所以“always 保证不丢数据”这句话的完整形式是：在底层存储的 fsync 延迟足够低且稳定的前提下，always 保证不丢数据。当这个前提不成立时，丢失的不是数据，而是吞吐和延迟的可预测性。

混合持久化组合的是机制，不是边界

Redis 4.0 引入的混合持久化（AOF 以 RDB 快照开头，后接增量命令）常被理解为“取两者之长”。它确实在重启速度上取得了 RDB 的优势，在增量恢复上保留了 AOF 的粒度[reference:12]。但组合机制并不消除任何一个机制自身的边界：混合持久化中的 RDB 头仍然需要 fork 生成，AOF 尾部仍然受 appendfsync 策略约束，fork 的 COW 内存放大和 everysec 的丢失窗口原样保留。

把 RDB 和 AOF 同时开启，只是让系统在一种机制失效时还有另一种可以依赖，而不是让“持久化”变成一个无条件成立的属性。官方建议同时使用两者的措辞是“如果你想要某种程度上可比 PostgreSQL 的数据安全性”[reference:13]——“某种程度”这个词不是修辞上的保留，而是对边界存在的明确承认。

持久化不是一个开关，是一组需要被兑现的条件

把 Redis 的持久化路径串起来，会看到一条一致的逻辑：每一个承诺都绑定了一组它自己无法控制的外部条件。RDB 的“瞬时快照”绑定的是 fork 之后写入不能太密、内存不能太紧、THP 最好关掉；everysec 的“一秒窗口”绑定的是 fsync 的尾延迟不能超过秒级；always 的“不丢数据”绑定的是存储 IOPS 不能成为瓶颈。这些条件中的大部分属于部署环境，而不是 Redis 进程内部。

因此，判断 Redis 持久化是否“够用”，比读性能数字更有用的，是先确认这些条件在自己的环境里是否成立。当条件成立时，对应的承诺是可靠的；当条件不成立时，承诺不会“打折扣地兑现”，而是以 COW 内存翻倍、主线程被 fsync 拖住、或吞吐撞上 IOPS 天花板的形式，把代价转移到另一个维度上。持久化的真正边界，不在 Redis 的配置文件里，而在你对“什么条件下这个保证成立”这个问题的回答里。