为什么同样配置的独服（独立服务器，即整机物理服务器租给你的模式），一台 4K 随机写入能跑到 300MiB/s 以上，另一台却只有 20MiB/s 不到？很多站长拿到机器先测 CPU 跑分和带宽（网络传输速率），磁盘随手一个 dd 就下结论”这机器 IO 不行”，然后在独立服务器租用排行里换了一家又一家。其实多数情况下硬件没缩水，差距出在 RAID（磁盘冗余阵列）卡的缓存策略上：Write Back 与 Write Through 两种模式，在我的实测里随机写差距能到 17 倍。这篇文章帮你搞清楚两种策略的原理、实测差距有多大、以及什么时候不该盲目开 Write Back。
先看原理：两种缓存策略到底在做什么
要理解差距，得先看数据写入的路径。RAID 卡上有一块 512MiB 到 4GiB 不等的板载缓存，操作系统发起的写请求先到这里，再由卡决定什么时候真正落到磁盘。Write Through（直写模式）的策略很保守：数据必须真正写进磁盘扇区，RAID 卡才向操作系统返回”写入完成”。你的每一次 4K 小写，都要等物理盘片转到位、磁头写完，队列深度再高也躲不开机械盘的物理延迟。优点是掉电不丢数据，代价是小块写入性能被机械盘牢牢锁死。
Write Back（回写模式）则激进得多：数据只要写进 RAID 卡的板载缓存，就立刻返回”完成”，真正的落盘由卡在后台择机批量执行。小块随机写在缓存里被合并、排序，最终变成接近顺序的大块写入，性能自然高出一个量级。但代价也写在脸上：缓存里那些”已确认但未落盘”的数据，一旦机器掉电就凭空消失，文件系统直接损坏都是轻的。
这也是 Write Back 必须搭配 BBU（电池备份单元）或超级电容的原因：断电后由电池维持缓存供电，最长撑 72 小时，等来电再补写。没有这层保护，等于把数据库一致性押在机房市电上。两种路径的差异可以看下面这张图。
测试环境与实测方法
测试平台是一台双路 2680v4 的独服，RAID 卡为常见的企业级 2GiB 缓存型号，一组 RAID10 挂 4 块 7200 转 SATA 企业盘，一组 RAID5 挂 6 块同型盘，系统 Debian 12，xfs 文件系统。工具用 fio，这是行业标准的 IO（输入输出）测试工具，参数直接给出方便复测：
- 顺序写：fio –name=seq –rw=write –bs=1M –iodepth=32 –direct=1，取 60 秒均值
- 随机写：fio –name=rand –rw=randwrite –bs=4k –iodepth=32 –direct=1 –numjobs=4
- 随机读：fio –name=randread –rw=randread –bs=4k –iodepth=32 –direct=1
两个注意点：必须加 –direct=1 绕过操作系统页缓存，否则测的是内存不是磁盘；切缓存策略要在 RAID 卡 BIOS 或管理工具里改，改完重启一次再测。每轮测试前我都执行 drop_caches 并等 30 秒冷却，每组数据取三轮中位数。顺带一提，很多机房的默认策略是 Auto 模式：BBU 健康时自动走 Write Back，电池故障或充放电时自动降级到 Write Through——这就解释了为什么同一台机器不同时间测分，IO 忽高忽低。
实测数据：差距比想象中更极端
先给结论：顺序写差距最小，随机写差距最狠。RAID10 下 1M 顺序写，Write Through 380MiB/s，Write Back 410MiB/s，只有不到一成的差距，因为 1M 大块本身就能喂饱机械盘的顺序吞吐。但 4K 随机写就是另一个世界了：Write Through 只有 1.8MiB/s（约 460 IOPS），Write Back 冲到 31MiB/s（约 7900 IOPS），差了 17 倍。RAID5 更惨烈，Write Through 下 4K 随机写因为校验盘惩罚只有 0.9MiB/s，跑数据库直接卡到怀疑人生；切 Write Back 后回到 19MiB/s。随机读两项策略差距不大，都在 260MiB/s 上下，因为读路径不经过缓存确认机制。
真实业务比裸数字更能说明问题。同一套 MySQL 在 Write Through 的 RAID10 上跑 sysbench，每秒事务数 420；切 Write Back 后升到 3800，高峰磁盘 util 从 98% 掉到 61%。如果你的机器 4K 随机写长期在 2MiB/s 以下，先别急着怪商家超售，查一下缓存策略，大概率它正跑在 Write Through 上。
Write Back 不是免费的午餐：BBU 与掉电风险
性能这么香，为什么机房不默认全开 Write Back？因为它的风险链条比多数人想象的长。第一个环节是 BBU 本身：锂电电池是损耗品，两到三年容量衰减到阈值以下，RAID 卡会把策略自动降回 Write Through，如果你的监控只看 IO 吞吐，会觉得”机器莫名其妙变慢了”，实际是电池到寿了。第二个环节是充电窗口：BBU 周期性充放电学习时，Auto 模式的卡同样会临时降级，很多一周一次的”IO 抖动”就是这么来的。第三个环节最致命：电池只保得住缓存里的数据，撑不住机房整体断电加 UPS（不间断电源）切换失败的极端情况，此时缓存里未落盘的写入全部蒸发，MySQL 的 ibdata 损坏、ext4 日志错乱都见过实锤案例。
还有一条容易被忽略的灰色地带：部分半管理型机房允许客户自己改策略，但机柜断电维护时并不等你优雅关机。所以改 Write Back 之前，先确认三件事：RAID 卡带 BBU 或超级电容且状态健康；业务有主从复制或定期快照兜底；机房计划内维护前会提前通知。三个条件缺一个，我建议老老实实留在 Write Through。选购前想系统了解独服硬件怎么核验，可以参考新手必读的独服常见术语拆解，先摸清硬件再谈调优。
不同业务场景该怎么选
实测数据摆在这里，选择反而变得简单，关键是把业务写入模式对号入座。数据库、论坛、电商订单这类小块随机写密集的业务，Write Back 加 BBU 是标准答案，17 倍的随机写差距意味着同一台硬件能多扛一个量级的并发；纯静态下载、备份存储、日志归档这类顺序写为主的业务，两种策略差距不到一成，留在 Write Through 完全合理；跑虚拟化的宿主机小写比例高，建议 Write Back 加 BBU，并把电池巡检纳入月度例行。
不能免俗地提一句选机层面：长期跑重 IO 业务，下单前直接问服务商”RAID 卡缓存策略是什么、有没有 BBU、能不能自选”，答不上来的基本可以排除。在独服与整机租用的横向对比里我也反复强调过，硬件参数表之外的固件策略，才是拉开同配置机器实际体验的隐形变量。拿我做测试的这台机器来说，它来自 Hostease 的独服产品线，下单时确认了 RAID 卡策略可自选、带 BBU，这也是我愿意拿它跑长时间写入测试的前提。
总结与行动建议
总结一下实测结论：顺序写两种策略差距不到 10%，4K 随机写 Write Back 领先 17 倍，代价是必须用 BBU 兜住掉电风险；不少”IO 缩水”的投诉，实际是 Write Through 或 BBU 老化降级在背锅。建议拿到独服后先按本文参数跑一轮 fio 随机写，低于 5MiB/s 就去查缓存策略和电池状态。如果业务是数据库类重写负载，推荐选购确认支持 Write Back 加 BBU 的机器；如果只是静态站和下载站，Write Through 反而更省心。BBU 是损耗品，建议每季度检查一次电池健康度。
