深入理解Write-Through与Write-Back：缓存写策略的数据安全与性能权衡

先把一个最容易被忽视的事实放在前面：很多人以为 Write-Through 和 Write-Back 只是"两种缓存写法，性能有高有低"，但实际上它们背后是两套完全不同的数据安全哲学。调错一个存储系统的写策略，轻则吞吐量腰斩，重则掉电丢数据——而且丢得十分优雅，让你连复盘的机会都没有。所以不管你是写驱动、做嵌入式、搞数据库，还是单纯在折腾文件系统参数，这两个词都值得彻底吃透。

这篇文章我会从缓存写策略的底层机制说起，把 Write-Through 和 Write-Back 的完整数据链路、脏数据的生命周期、真实场景下的选型逻辑以及崩溃恢复时的差异全部揉开讲清楚。内容既有原理推导，也有我在实际项目里踩过坑之后沉淀下来的经验，适合所有跟存储、缓存、IO 路径打过交道的人。

1. 两种写策略的底层差异：缓存快不代表一切

先别急着对比性能。我们得先建立一个共识：无论 Write-Through 还是 Write-Back，它们解决的都是同一个问题——当 CPU 或应用往缓存里写数据时，这些数据什么时候、以什么方式落到下一级存储（主存/磁盘/远端）去。

这个"什么时候落"的决策，才是一切差异的源头。

1.1 Write-Through 的基本数据链路

Write-Through 的策略非常直白：写操作必须等数据同时写入缓存和下一级存储，才算真正完成。

也就是说，当你往一个 Write-Through 的缓存里写一个字节时，这 8 个比特会被同步推给下一级。只有在下一级确认接收（不一定是落盘成功，但至少是交给下一级的控制逻辑）之后，这次写操作才会返回成功。整个过程里，缓存更像一个"顺带更新"的旁路设备，而不是一个"拦截并缓冲"的中间层。

用代码来表达的话，Write-Through 的写入路径大概是这样的：

c复制int write_through_write(void *cache_line, void *backing_store, void *data) {
    // 第一步：写缓存
    memcpy(cache_line, data, CACHE_LINE_SIZE);
    // 第二步：同步写下一级存储，等待返回
    int ret = backing_store_write(backing_store, data, CACHE_LINE_SIZE);
    if (ret != SUCCESS) {
        // 下一级写失败，这次写操作就是失败的
        return FAIL;
    }
    // 第三步：两个地方都写完了，才返回成功
    return SUCCESS;
}

注意这个 if (ret != SUCCESS) 分支。在 Write-Through 模式下，缓存必须承担一个很微妙的角色：如果下一级存储写失败了，缓存这一行要不要回滚？不做回滚的话，后续读操作会读到"缓存里有但底层没有"的假数据，这时候 Write-Through 的一致性承诺就会被打破。所以大多数严谨的实现会同时把缓存行失效掉，让读操作直接穿透到底层。

这个同步等待的行为，决定了 Write-Through 的写延迟永远大于等于下一级存储的写延迟。你缓存再快也没用，因为最终瓶颈卡在慢的那一端。

1.2 Write-Back 的写路径：先记账，后还债

Write-Back 就完全是另一套逻辑了。核心原则是：写操作只要落到缓存里就立即返回成功，至于什么时候同步到下一级，那是后面的事。

所以 Write-Back 的写入路径几乎只有一个操作：

c复制int write_back_write(void *cache_line, void *data) {
    // 只有一步：把数据写进缓存，标记这行数据是脏的
    memcpy(cache_line, data, CACHE_LINE_SIZE);
    set_dirty_bit(cache_line, 1);   // 立个 flag，告诉后面的人"这笔债还没还"
    return SUCCESS;                 // 立即返回，不等底层
}

这行 set_dirty_bit(cache_line, 1) 是整个 Write-Back 的命脉。它意味着从这一刻起，缓存里的这行数据和下一级存储里的数据是不一致的，这种不一致被显式记录下来——这就是脏行（dirty line）。

既然是"先记账，后还债"，那问题就来了：债什么时候还？如果一直拖着不还，缓存总有被填满的一天；如果每次写一点就立刻还，那性能优势又没了。所以 Write-Back 还债时机有一套专门的调度逻辑，关键触发条件包括：

• 缓存行被替换时：新数据要占位置了，如果这个位置上的旧数据是脏的，得先把它写回。
• 缓存容量达到阈值：比如脏行占比超过 70%，开始强制回写。
• 周期性刷盘：系统每隔一段时间（比如 Linux 内核的 dirty_expire_centisecs）把超过一定年龄的脏数据写下去。
• 显式同步请求：应用调用 fsync()、fdatasync() 或 sync() 时，脏数据必须被强制落盘。

这套机制的本质，就是用一致性换取吞吐量：牺牲"随时崩溃都绝对安全"的保证，换来"写操作不被慢速底层拖后腿"的高性能。

1.3 用厨房的比喻收个尾

如果你对上面的原理还有模糊，我用一个厨房的比喻帮你在脑子里立个模型。

Write-Through 就像一个点菜后厨必须立刻把菜端上桌的餐厅。客人（CPU/应用）点了菜（写操作），后厨（缓存）不能只在自己菜单上记一笔就完事，必须等真正的大厨（磁盘）把菜做好端出去，才算这道菜完成。偶尔来的客人多，后厨再快，上菜速度也被大厨的手速锁死了。

Write-Back 则是另一种餐厅：先记在点单板上，告诉客人"您的菜我们已经收到啦"，然后趁空闲的时候、或者后厨小黑板写满的时候，再把单子累计传给后厨批量做。点单板（缓存）和实际上菜的菜（磁盘里的数据）经常是不一致的，但只要最后没有搞丢单子，大多数情况下客人体验会好得多——前提是餐厅别着火（掉电），否则小黑板上的单子可能一把火全没了。

这个比喻虽然糙，但把两种策略最核心的气质——同步等待 vs 异步缓冲——讲透了。

2. 脏数据机制：Write-Back 的命门不在性能，在"还债"策略

讲完基本链路，我建议你再往下挖一层。Write-Back 真正难的地方不是写缓存本身，而是脏数据的生命周期管理。这个问题处理不好，缓存命中率再高都白搭，因为最终你会发现系统的 IO 都花在"打扫卫生"上了。

2.1 脏行（Dirty Line）到底是怎么产生的

再回过头看那行代码：set_dirty_bit(cache_line, 1)。硬件层面，每个缓存行（cache line）旁边都会有一组状态位，其中最关键的就是脏位（dirty bit）。当一次写操作命中某个缓存行时，除了更新数据本身，还必须把头 1 改成状态机的"已修改"状态。这个过程在硬件流水线里是原子完成的，换句话说，不存在"数据更新了但脏位没来得及标"的中间状态。

但你真的以为脏位就只有一个 bit 吗？太小看工程了。在我见过的实际存储系统里，脏状态的管理粒度可以是：

比如 Linux 内核的 page cache，它的"脏位"实际上是一棵以 radix tree 组织的脏页树，内核要精确知道哪些页在哪个 bdi（backing device info）上挂着，这样才能在做 sync 时知道该把哪些页刷下去。这个粒度间的差异，直接决定了一个 Write-Back 系统在随机写场景下会被放大多少倍。

2.2 回写策略：谁排在你前面，谁排在你后面

遇到脏页不只是"找一个时间把它写了"这么简单。优秀的 Write-Back 实现一定会考虑回写顺序。最基本的两个极端：

• FIFO 回写：谁先脏，谁先写。逻辑简单，但会产生大量随机小 IO。因为如果应用写的是文件 A 的第 1 块、文件 B 的第 1 块、文件 A 的第 2 块……按时间顺序回写时会把磁盘寻道时间拖垮，原本连续的写变成了来回跳跃。
• 顺序整理回写（coalescing）：把大量随机小脏页在内存里累积，排序后合并成尽量连续的大块，再一次性写下去。SSD 也有类似机制，把小块写入合并成大块再落 NAND。

协整回写是实际产品里最常用的优化，因为它的收益实在太明显。一套硬件 RAID 卡在 Write-Back 模式下通常会做一件事：等脏数据积累到一定量（比如 1MB 或者配置的水位线），再把它们按 LBA 排序、整理了相邻区间，最后一次性写出去。效果就是顺序写的吞吐量远大于随机写，代价是掉电损失的窗口更大。

所以你会发现一个很有意思的现象：Write-Back 缓存越大，写性能越好，但掉电丢数据的窗口也越大。这不是巧合，它们是同一个机制的两面。

2.3 Write Allocate 与 No-Write Allocate：写缺失时的岔路口

还有一个经常被忽略、但实际调优时必须面对的点：当写操作没有命中缓存（写缺失）时，要不要先把数据读进缓存再改写？ 这一问有两派做法：

在 Write-Through 模式下，No-Write Allocate 是更合理的搭配，因为既然每笔数据直接落底层了，缓存不更新也罢，省掉一次毫无必要的底层的读。但在 Write-Back 模式下，Write Allocate 几乎是最佳拍档——把一个完整的底层块读进来，在缓存里改几个字节，标记脏，然后等批量回写时以一个完整块为单位写回。这样每一次随机小写最终也会变成一个"大块读 + 小块改 + 大块写"的节奏，底层不会因为跨小写被切成碎片。

实际调优里大家应该也会有体感：在 Linux 里如果大量使用 O_DIRECT（绕过 page cache）做随机写，你会发现 Write Allocate 的收益完全消失——因为根本没经过缓存。这就是为什么数据库类应用经常绕过 Write-Back 直接走 Write-Through 风格的 IO 路径，它们更喜欢自己控制缓存。

2.4 一个被我反复验证的教训：别把脏位只当状态位

讲一个我自己的血泪教训。早期我做过一套嵌入式存储方案，为了节省 SRAM 空间，我把脏位的存储给"优化"了一下，用一组 bit 而不是每个缓存行一个独立的字节。理论上这没问题，但我在做缓存行替换时漏了恢复脏位的操作，结果回写阶段把从未写过数据的区域也刷进了底层存储，直接把文件系统的元数据区写坏了。

从那之后我就养成一个习惯：无论用什么数据结构存脏位，替换缓存行时第一个动作必须是检查并保存脏位，然后立刻清除原行状态。这个顺序写错，数据一旦污染，就不是恢复能解决的问题，因为这个位置后续所有读操作都会命中错误数据，你已经没有办法知道哪些是用户写过的"合法脏数据"，哪些是纯垃圾。脏位在系统中的角色是记账本，记账本本身不能做任何"看起来优化"的压缩，除非你彻底证明状态转换是完备的。

当然这不是说你不能用位图压缩脏位——当然可以用，我也是这么干的。但测试时要专门为"覆盖写同一行""部分命中同一行""替换后再写回"这三种场景写针对性用例，而不是只测读写吞吐顺手验证一下。这比性能数字重要得多。

3. 真实系统怎么选：CPU、存储阵列、数据库各取所需

聊完机制，我们来点实战问题。为什么 CPU 缓存几乎清一色 Write-Back，而数据库日志必须 Write-Through？同样是存储介质，为什么有些企业级 SSD 要把 Write-Back 做得像 Write-Through 一样稳？这些选择背后没有一刀切的答案，每个系统都是在自己面对的矛盾里找平衡。

3.1 CPU 缓存：高速下的必然选择

CPU 的 L1/L2 缓存是 Write-Back 的典型代名词，而且几乎没有争议。原因是内存写入速度虽然比缓存慢两个数量级，但 CPU 没法承受每次 store 指令都等主存完成一次完整交互。可以算一笔账：3GHz 的 CPU，主存延迟大约 100ns，一次 store 如果走 Write-Through，指令吞吐上限直接被按到 1000 万次/秒左右，每周期算力再多都白搭。

但 CPU 的 Write-Back 不止是"写完就返回"这么简单。它必须配合 MESI 协议（一种缓存一致性协议）来保证多核之间不会读到彼此过期的数据。当 CPU0 写了缓存行 X 后，CPU1 想读 X，MESI 会在总线/片上网络上发起一次监听，让 CPU0 把 X 的最新状态共享出去。注意，这里涉及的一致性传递发生在缓存之间，不是每次写都落到内存，这比纯粹的 Write-Through 节省了大量片上带宽。

多核场景下 Write-Back 最经典的坑是伪共享（false sharing）。两个线程各自改写相邻的内存变量，但它们落在同一个缓存行里，每次修改都会导致整行在核心间流动，表现就是缓存一致性消息在整个系统里飞来飞去，性能雪崩。对策很简单但不够直观：把高频写的字段 padding 到 64 字节对齐，让它们不会共处一行。像是 C/C++ 里 alignas(64) 这种操作，做的就是这个事。

3.2 存储阵列与 SSD：当 Write-Back 遇上掉电保护

存储设备的 Write-Back 与 CPU 最大的不同在于：CPU 掉电，缓存同时丢掉，最多把正在计算的任务搞挂；存储设备掉电，如果缓存里还有等待落盘的数据，那是真丢数据，而且是用户数据，不是临时计算状态。

所以企业级 RAID 卡和 SSD 的 Write-Back 一般都有一个强制前提：有掉电保护机制。传统 RAID 卡的做法是板载缓存加电池备援（BBWC, Battery Backed Write Cache），掉电瞬间由电池给缓存和控制器供电，控制器有足够时间把脏数据刷进盘里。现代 NVMe SSD 的做法更细腻：固件例行地把缓存行搬运到 NAND 里的一个专门区域，靠电容放电保证这个搬运动作能完成，甚至保证元数据先于用户数据落盘。

你去看企业级 SSD 的规格书，几乎都会标注"Power Loss Protection"或"Enhanced Power Loss Data Protection"之类的字样。没有这个保护机制，你绝对不应该开启设备的 Write-Back 模式。我在选型时见过不少杂牌消费级 SSD 标称带缓存，但其实用的是便宜的 DRAM 且没有备电设计，掉一次电文件系统直接 SOS。这类盘的某些坑，真的不用自己踩一遍才知道怕。

对于没有掉电保护的消费级方案，我个人的经验是：要么让跑关键应用的设备只采购支持 Power Loss Protection 的型号，要么就老老实实允许把"大部分缓存失效"当作系统设计的一部分——比如数据库的 redo log 不要放这种设备上。

3.3 数据库日志：Write-Through 的执念

数据库系统是 Write-Through 的最忠实拥趸，特别是在 redo log / WAL（Write-Ahead Logging）这种关键路径上。原因非常直接：事务提交的语义要求日志记录先于数据页落盘。如果日志写到缓存里就说"已提交"，一旦崩溃，你根本不知道日志到底在不在盘上，事务原子性直接破产。

所以数据库的 commit 路径在操作系统层面做的事是：把日志内容写进 page cache，然后立即调用 fsync() 或 fdatasync() 强制刷盘，这个过程本质就是一次 Write-Through。也就是为什么你去调数据库性能时，总绕不开那三个参数 innodb_flush_log_at_trx_commit（MySQL）或 synchronous_commit（PostgreSQL）——它们在决定你愿意把多少个事务的提交都"押"在 Write-Back 的缓存安全性上。

有些系统和配置（比如 innodb_flush_log_at_trx_commit = 2）允许日志只写到操作系统缓存就返回，这是主动降级到了 Write-Back，换取吞吐量，但代价是操作系统崩溃时最多丢最近 1 秒的已提交事务。这不是不能用的配置，但你必须明确知道自己做了一个安全妥协。

3.4 文件系统层面：写策略的"三不管"地带

还有一个经常被忽视的层次——文件系统本身的日志和元数据更新策略。ext4 的 data=ordered 和 data=writeback 是最直观的对比：

• data=ordered：先保证文件数据落盘，再写元数据日志（准确说是先于 metadata 提交），这样崩溃后不会出现"文件系统结构已更新但数据为空"的情况。
• data=writeback：把文件数据的落盘交给通用写回机制，元数据日志可能先于数据落盘。性能更好，但崩溃后可能出现文件内容与元数据不一致，也就是文件里有旧的或零的数据。

如果你不知道自己在跑什么模式，建议查一下当前挂载参数。因为很多默认配置为了安全用 ordered，而以读多写少为主的某些场景（比如模板服务器）换成 writeback 反而能得到很大的吞吐提升——前提是你接受崩溃后那些还没刷盘的数据块变成旧数据。

这说明什么问题？它说明 Write-Through 和 Write-Back 不是非此即彼的二选一，更像是一个沿着数据链路逐级下探的选择梯度：从 CPU 到 page cache 到文件系统日志到磁盘控制器再到物理设备，每一级都可以有自己的写策略，而且它们会层层叠加，共同决定最终的数据安全性和性能表现。

4. 崩溃场景的行为差异：数据安全的分水岭

前面我反复提到"掉电丢数据"，这一节我们正面把这个问题彻底拆开。Write-Through 和 Write-Back 在正常运行时的差别，可能只体现在性能和延迟上；但一旦发生崩溃，两者的行为差异会立刻变成"数据保全"和"数据永久丢失"之间不可逾越的分界线。

4.1 Write-Through 的崩溃语义：恢复窗口最小

Write-Through 之所以在数据安全上有天然优势，是因为它在"写操作返回成功"这个时间点，目标数据已经在两个物理位置（缓存 + 底层）同时存在了。这带来一个非常好的属性：

• 如果写操作还没有返回成功就崩溃了，那你最多丢"这次写从未发生过"——你在崩溃后看到的数据是上一次成功的状态，这是可接受的，并且很多应用在设计时已经能容忍这类回滚。
• 如果写操作已经返回成功，那么即使后面崩溃，数据已经在底层，恢复后一定能看到它。

所以 Write-Through 系统在崩溃恢复时要做的事最少：没有任何"哪些数据原本应该在底层但还没有"的悬案。它的恢复逻辑基本只需要处理掉"写了一半"这种物理层面的损坏（比如扇区撕裂），而不用费心去猜测"哪些缓存行是脏的、要不要刷下去"。

这也是为什么数据库日志、文件系统事务日志这类对一致性要求极高的数据，无论如何都要走 Write-Through 语义——即使性能差点，但崩溃恢复的代码足够简单，简单到可以用穷举测试来覆盖所有分支。

4.2 Write-Back 的崩溃语义：丢数据的窗口有多大

Write-Back 的麻烦在于，当你返回成功的那一瞬间，数据只存在于缓存里，底层存储还毫不知情。如果下一秒系统崩溃，这行数据就凭空消失了。虽然下一次上电时你可以通过日志或其他机制发现"某笔数据本来应该存在"，但如果没有额外的跨层冗余，你没有任何办法找回它。

丢失窗口到底有多大？这取决于脏数据的"寿命"：

• 如果脏数据刷盘周期是 5 秒，那最坏情况下你要承担 5 秒内的写数据丢失。
• 如果缓存在写满时才回写，且脏缓存快满了，那可能只需要几百毫秒就会刷一次，丢失窗口反而小。
• 如果加上"无新写入但脏页迟迟不刷"的静默状态，脏数据可能在那里躺上数十秒甚至几分钟，只要开发者没有真正理解内核刷盘参数的默认值。

这里有个很多人没注意到的细节："丢数据"不等于"丢文件"。比如你在写一个文件的过程中崩溃，Write-Back 缓存里还存着文件的最后几 KB，而文件系统元数据（比如文件大小字段）可能已经因为另一个缓存的落盘而更新了。上电后你看到的文件大小比实际内容大，尾部是一堆零或者旧数据，这种"有文件但数据错乱"的状态，比直接少了整个文件更难排查，因为错误不明显。

4.3 fsync、sync、O_DIRECT：你手里控制崩溃语义的遥控器

既然知道了 Write-Back 的软肋，那么我们有没有办法在需要安全时临时切换到 Write-Through？答案是可以的，而且操作系统提供了三个层次的控制手段：

第一层：sync() / fsync() / fdatasync() 强制刷盘。这是最常用的手段，当你调用 fsync(fd) 时，内核会把这个文件相关的脏页全部写回底层存储，并且等待写完成。这个调用返回后，你就拿到了"数据已在磁盘上"的保证。要注意的是 fdatasync() 只会刷文件数据本身，不会同步文件大小等元数据，所以如果你改写了文件长度，必须用 fsync()。

第二层：O_DIRECT 绕过缓存直接写底层。打开文件时加 O_DIRECT 标志，写操作会直接下沉到块设备层，不经 page cache。这样每次 write 都走 Write-Through，延迟增加但数据安全立刻提升。注意 O_DIRECT 要求内存对齐（通常 512B 或 4KB），而且对写缓冲区的生命周期管理更严格，做不好容易踩对齐的坑。

第三层：刷盘参数调节。在 Linux 下，你可以调整三个和 Write-Back 窗口直接相关的参数：/proc/sys/vm/dirty_ratio（脏页占系统内存的百分比阈值）、/proc/sys/vm/dirty_background_ratio（后台开始刷脏页的百分比阈值）、/proc/sys/vm/dirty_expire_centisecs（脏页在内存里允许呆的最大年龄，单位是厘秒）。把它调低，Write-Back 的缓冲窗口变小，更接近 Write-Through；调高则相反。

我在生产环境里的经验是，数据库机器上千万别盲目保持默认的 20% / 10% ratio。如果一个 64GB 内存的机器允许攒 12.8GB 脏页才触发后台回写，一旦断电，你一次性可能丢掉近 13GB 的应用数据，这还不包括文件系统元数据不一致带来的连带问题。我一般会按应用的重要性把 dirty_ratio 调到 5%~10%、dirty_expire_centisecs 调到 300~500，并且配合 UPS 和文件系统自身的日志能力来兜底。

4.4 一次丢数据事故的完整复盘

讲一个我印象深刻的项目经历。几年前给某工业设备做存储子系统，硬件是一块消费级 SSD + 一个自研的 FTL 缓存模块，缓存模块默认开启了 Write-Back，因为厂家说这个模块"有断电保护"。某次现场测试，他们在设备运行中直接拉闸断电，重启后设备上一个小型配置文件的内容变成了半年前的老版本——文件在，数据是旧的。

排查链路是这样展开的：

1. 第一步，怀疑文件系统日志损坏。检查 ext4 journal，一切正常，说明崩溃顺序没有破坏元数据。
2. 第二步，怀疑 SSD 的 FTL 映射错误。跑了一整轮 SMART 检测和坏块扫描，没有任何异常。
3. 第三步，回看缓存模块的设计。才发现它所谓的"断电保护"只保护了 FTL 映射表，并没有对用户数据脏页做紧急回写，也没有把脏数据镜像到 NAND 的备用区。

真相是：配置文件被上一轮写入标记为脏页，在缓存里待了大概 3 分钟没有刷盘，然后被一个新页淘汰掉了。淘汰时它触发一次回写，但这次回写刚好发生在拉电瞬间的不稳定供电窗口里，写到一半失败，但 FTL 映射已经更新。重启后，系统以为数据已经落盘，实际 NAND 上对应的还是半年前的旧内容，缓存里也没有最新版本，于是这个文件"优雅地回退了半年"。

自此以后，我给自己定了一条铁律：凡是做工业/嵌入式存储，没有完整 Power Loss Protection（不光保映射表，还要保用户数据回写）的模块，一律不许开 Write-Back。这背后是"一致性承诺必须是可以验证的，而不是听起来足够完备"的教训。

5. 性能实测与参数调优：用数据说服自己

原理聊了这么多，最终还是要落到"怎么测、怎么调"上。我自己不太相信纯理论推导出来的性能结论，因为缓存写策略对 IO 性能的影响往往和负载特征强相关，同一套配置换一种负载结果可以完全逆转。这节分享一下我常用的测试方法、对比结果、以及调优时容易踩的误区。

5.1 第一轮基线测试：先看吞吐和延迟分布

我建议先用 fio 分别测 Write-Through 和 Write-Back 在纯顺序写和纯随机写下的表现。顺带提一句，fio 非常依赖参数的写法，不写 --direct=1 的话，测试结果实际上是绑定在 page cache 的 Write-Back 行为上的，根本评估不到设备级的策略差异。

一条最基础的命令长这样：

bash复制fio --name=writeback-test \
    --filename=/dev/nvme0n1 \
    --rw=write \
    --bs=64k \
    --iodepth=32 \
    --ioengine=libaio \
    --direct=1 \
    --size=4G \
    --runtime=30 \
    --time_based \
    --group_reporting

把 --rw=write 换成 --rw=randwrite 就是随机写。如果你要对比设备策略的话，可以在设备的固件工具/驱动里切换 Write-Through 与 Write-Back 模式，分别跑一遍，拿到的数据才有可对比性。

分享一次实测数据（NVMe SSD，设备支持双模式切换，64KB 块，队列深度 32）：

高下立判。Write-Back 在带宽、IOPS、延迟三个维度全面碾压 Write-Through。但你千万别看到这张表就下结论，因为后面还有第二张表等着你。

5.2 崩溃点统计测试：性能数字背后的真实代价

同一块盘，我做了一个更残酷的测试：在连续随机写负载运行过程中随机掉电，重复 100 轮，统计每轮重启后文件系统 fsck 结果和数据完整度。结果如下：

这个第二张表才是关键。如果你的系统里没有掉电保护，Write-Back 的性能优势在未来某天会以"数据遭遇永久损坏"的形式全数偿还。

同时也注意，带完整断电保护的 Write-Back 反而可以做到 100% 完整率，因为它固件里做了双缓存镜像和掉电瞬间的紧急回写，性能和数据安全兼得。所以不要一概而论地贬低 Write-Back，真正危险的是"裸奔的 Write-Back"。

5.3 Linux 下面向 Write-Back 的调优思路

如果确认某一层的数据可以接受 Write-Back，那么调优的核心就是控制脏数据的规模与生命周期。以下是我在 Linux 生产环境里常用的几个调整项，附带说明而不是直接丢参数。

先看状态。运行 cat /proc/meminfo | grep Dirty，会看到 Dirty: 一行，它表示当前有多少页在内存里等待写回。想要实时监控回写活动，可以用 iostat -x 1 观察 w_await 和 aqu-sz——如果 w_await 很高且 aqu-sz 持续大于队列深度，说明刷盘线程已经跟不上应用产生的脏数据速度了。

然后是调参。有三个 /proc/sys/vm/ 下的参数值得按需调整：

留意一点：dirty_background_ratio 和 dirty_ratio 在较新的内核上还引入了基于字节的 dirty_background_bytes 和 dirty_bytes 选项，单位是字节。如果机器内存差异很大（比如 4GB 和 256GB 的机器用同一个百分比，实际脏页总量差了几十倍），用 bytes 形式会更可控。但官方文档提示这些参数在设置时不能同时使用百分比的对应项，不然行为未定义，取值时别混用。

在实际压测中，我通常用如下思路确认参数是否合适：持续写入 10 分钟，同时观察 dirty_expire_centisecs 到期后在 3 秒内是否触发均衡的刷盘动作（用 vmstat 1 看 bo 列的块输出）。如果 bo 一直是 0，说明系统太乐观了，脏数据全都憋在内存里；如果 bo 忽大忽小且伴随 iowait 飙升，说明阈值设得太激进。调参不是玄学，它是一套"让刷盘动作既不会太频繁、又不会太滞后"的反馈调节。

5.4 提防性能测试中的"幻觉指标"

还有一个非常重要的提醒：测 Write-Back 性能时，很容易被一些物理真相掩盖。

第一个幻觉是"随机写性能翻倍"的表象，但 Write-Back 其实把写放大了。一次 4KB 的随机写，落到底层往往会转换成一次 16KB 甚至 64KB 的块写，因为合并/填充机制把相邻数据也带了进去。从应用视角看是高性能随机写，从底层介质看是更频繁的擦写和更快的损耗。如果不注意寿命监控，NAND 的寿命可能被无形中吃掉一截。

第二个幻觉是"Write-Through 慢无可救药"。实际上现代设备在 Write-Through 模式下也有大量优化，比如 NVMe 的 Write-Through 可以用高效的命令合并和完成中断减少机制来隐藏部分延迟。我见过对延迟不敏感、但对绝对一致性敏感的用户，用 Write-Through 配高队列深度照样跑到不错的吞吐。所以不要让"性能一定差"的偏见阻止你为正确性选型。

第三个幻觉是"Benchmark 的负载代表真实应用"。几乎没什么应用会像 fio 那样，纯做 4KB 随机写而且永远不读。混合读写比例、IO 复用度、数据压缩等因素，都会极大影响写策略的实际表现。我对选型的建议永远是：先把生产环境负载录制成 trace，然后用 trace 回放来对比两种模式，这比任何通用 benchmark 都靠谱一个数量级。

6. 扩展思考：分布式系统里的 Write-Through 与 Write-Back

最后再扩展一层，因为不少做后端开发的人接触这两个概念，其实是从分布式存储、缓存组件（Redis、Memcached 这类）开始的。分布式系统和单机存储的差异在于，"下一级存储"从一块磁盘变成了网络对端的副本，延迟和故障模型都更复杂，但核心权衡逻辑依然成立。

6.1 分布式缓存中的 Write-Through：写放大与一致性

在分布式缓存里，Write-Through 的典型应用是"边写数据库边更新缓存"的模式：应用发起的每次写请求，先更新数据库，再同步更新缓存。这个模式在一致性方面很直观——你永远不会读到缓存里的旧数据（前提是更新顺序没有竞态），但副作用极其明显：每一次写都会变成两次写操作，数据库写一次，缓存写一次。如果缓存不是必需热数据，这次缓存写就是纯粹的性能浪费。

实际项目里我踩过一个竞态坑：先写数据库再更新缓存，如果更新缓存失败（比如 Redis 短暂不可用），那缓存里还是旧值，接下来的请求会一直读取旧数据。兜底方案有两个，要么把缓存更新改成异步消息重试，要么接受"短暂读到旧值"，但明确设置短 TTL 来自愈。这里没有银弹，一切取决于业务愿意接受多长的最终一致窗口。

6.2 分布式日志与消息队列：Write-Back 的优雅实践

与之相对，Kafka 这类消息队列的存储引擎，可以看成是 Write-Back 思想的一种工程化变体。它们默认批量累积消息，等攒够一批或者到时间阈值再写磁盘，这样单条消息的 fsync 代价被批量摊平，吞吐量飙升数倍。配合多副本机制，即便单机丢了写缓冲里的数据，其他副本可能还有完整数据，所以 Write-Back 的丢数据风险被副本冗余对冲了。

这种"多副本对冲 + Write-Back 缓冲"的思路在分布式系统里非常常见。事实上，灾难恢复能力往往不是来自某一点绝对不丢，而是来自所有副本在同一时间崩溃的概率小到可以接受。这让数据安全从"同步语义的硬保障"变成了"概率模型的软保障"。理解了这一点，你就知道为什么 Kafka、Raft 这类系统能相对放心地使用批量刷盘，而不是寸步不离地守着 fsync。

6.3 个人建议：画出你的数据链路，标出每一层的写策略

无论做单机存储还是分布式系统，我强烈建议你花半天时间，把你项目里的完整数据链路画出来，并在每一层旁边标注：

• 这一层是 Write-Through 还是 Write-Back？
• 如果是 Write-Back，脏数据的最大存活时间是多少（实际数值，不是设计值）？
• 这一层掉电/崩溃时，写入返回成功但实际没丢的可能性有多大？
• 上一层和下一层的写策略组合起来，最坏情况下数据会丢失多少？

画完这张图之后，绝大多数"莫名其妙的数据异常"其实都能定位到某一层的 Write-Back 窗口上。这张图比任何监控面板都更能救命，因为它把隐含的安全承诺显式化了。

我在做存储相关的方案评审时，第一件事就是让提交方案的团队画这张图，画不出来或者标注模糊的，很可能说明写策略根本没有被认真设计过，只是巧合地在用默认行为运行着。

7. 收尾想说的话

最后分享一点点个人的体会，不是总结，就是几个“早该有人告诉我”的经验。

写策略这件事没有绝对的对错，只有你愿不愿意为性能付出安全代价、以及愿不愿意为安全牺牲性能。真正负责的工程实践，是在你接受了其中一种策略的同时，明确写出了最坏情况下的数据损失边界，并且让这个边界是可测试的。我最怕听到的一句话是"这里有缓存，应该没事"——"应该"这个词一旦出现在存储方案里，就意味着你还没有真正理解这台机器在断电那一刻的行为。

另外一个小建议：如果你刚开始接触这块，不要急着讨论参数调优，先把"Write-Through 返回成功 = 数据在底层"和"Write-Back 返回成功 = 数据可能在缓存、也可能在底层"这两条语义刻在脑子里。所有的高级话题——批量回写、Crash Consistent、Redo Log、FUA（Force Unit Access），甚至 NVMe 的各种缓存模式——全都是这两条语义在不同硬件层次上的变形和展开。抓住这个根源，你后面看任何存储相关的论文或源码，都会感觉顺很多。

所以你手上现在正在做的系统，到底能容忍多少数据的丢失？这个问题的答案，本质上就是你该在这两种模式里选择的答案。