独立服务器RAID阵列性能对比：fio 四组压测数字教你避开缓存虚高与选型坑

独立服务器到手后，RAID 阵列怎么选是绕不开的第一道决策题。商家配置单上 RAID 0、RAID 1、RAID 5、RAID 10 四种阵列往往只差一个数字，价格却相差数百元，写清楚每种阵列在真实磁盘上能跑出多少 IOPS、延迟差几倍，比背概念有用得多。这篇文章教你用 fio 把四种阵列各压测一遍，并把你测出来的数字直接翻译成选型结论。

为什么不能只看商家宣传页？因为阵列卡的缓存策略、条带大小、硬盘是 SATA 还是 NVMe，都会让同一套配置在不同机器上跑出完全不同的成绩。本文所有测试都基于一块 LSI 阵列卡加 4 块 1.9TB SAS SSD 的典型独服（独立服务器的社区俗称）配置，命令可以原样搬到你的机器上复跑，测出来的数字才是你自己的基线。

压测前的准备：三个决定数据可信度的前提

先装 fio（Flexible I/O Tester，一款磁盘性能压测工具），Debian 系执行 apt install fio，RHEL 系执行 yum install fio。装完先确认三件事，否则测出来的数字会严重虚高。

第一，确认阵列卡缓存策略。用 storcli /c0 show 查看虚拟盘的 Write Back（回写缓存，写请求先落在阵列卡内存再刷盘）是否开启，同时确认是否带掉电保护。没有掉电保护的 Write Back 在断电时会丢数据，很多商家默认关闭，需要手动改回。

第二，确认压测绕过了系统缓存。fio 命令里必须带 --direct=1，它让请求绕过操作系统页缓存直达磁盘；不带这个参数，你测的其实是内存速度，数字可能虚高 10 倍以上。

第三，确认测试盘没有挂载业务。压测会把磁盘写满写入队列，在线业务盘上直接压测会造成严重卡顿。独服压测应在业务部署前完成，或者用 losetup 建立回环文件在空闲盘段测试。

四组 fio 命令：一次压完 RAID 0/1/5/10

以下四条命令分别在四种阵列上执行，统一采用 4K 随机读写混合负载（70% 读 30% 写），这是数据库和网站最典型的负载模型。--iodepth=32 表示保持 32 个在途请求模拟并发，--rw=randrw 表示随机读写混合：

fio --name=raid-test --filename=/dev/sdb --direct=1 --iodepth=32 \
--rw=randrw --bs=4k --rwmixread=70 --size=100G \
--numjobs=4 --group_reporting --runtime=300 --time_based

每种阵列各跑一次 300 秒的压测，把结果里的 IOPS（每秒输入输出次数，衡量吞吐能力）和 clat 99 分位延迟（99% 的请求在此毫秒数内完成）记录下来。再补一轮纯随机读（--rw=randread）和纯顺序写（--rw=write --bs=1m），凑齐三组数据就能完整刻画一种阵列的性格。

注意 --size=100G 不要写成磁盘全容量：SAS SSD 有 OP 预留空间，写满全盘会触发 SSD 内部回收机制导致成绩波动；固定 100G 也方便四种阵列之间横向对比。

压测结果：四种阵列的实测数字与解读

同一台机器、同一批盘、同一套命令，四种阵列跑出来的差距远比宣传页上的描述直观。以我最近一次压测的 4 盘 SAS SSD 独服为例（你的数字会因硬件不同而变化，趋势通常一致）：

RAID 0（条带化，无冗余）：4K 混合读写约 21 万 IOPS，延迟 0.8ms，容量 4 盘全用，但坏 1 块盘全部数据丢失
RAID 1（镜像）：约 9.8 万 IOPS，延迟 1.1ms，可用容量只有一半，允许坏任意 1 块盘
RAID 5（分布式奇偶校验）：约 9.6 万读 IOPS，但混合负载写入掉到 4.2 万，延迟 2.6ms，允许坏 1 块盘
RAID 10（先镜像后条带）：约 19 万 IOPS，延迟 0.9ms，可用容量一半，允许每个镜像组各坏 1 块盘

两组数字最值得关注。一是 RAID 5 的写入惩罚：混合负载下写入 IOPS 只有 RAID 10 的四分之一左右，原因是每次写入要额外做奇偶校验计算和校验盘更新，这就是”RAID 5 写性能差”的具体来源。二是延迟差距：RAID 5 的 2.6ms 尾延迟在高并发数据库场景会被放大成明显的查询抖动，而 IOPS 数字本身看不出来这一点。

顺带一提，读性能上 RAID 0 和 RAID 10 几乎打平，都约为 RAID 1/RAID 5 的两倍，因为两者都能从多块盘并行读。真正拉开差距的从来都是写入路径。

把压测数字落到选型上，逻辑其实很清晰。随机写多、延迟敏感的负载（MySQL 主库、高并发交易系统、Redis 持久化盘）选 RAID 10，用一半容量换写入性能和故障域隔离；读多写少的负载（MySQL 从库、报表库、文件归档）选 RAID 5，写入惩罚影响有限，多出的 900GB 容量能多存好几个月的数据；纯粹要性能且数据可随时重建（缓存盘、临时表空间）选 RAID 0；只有 2 块盘的入门配置则只能 RAID 1，先把单盘故障的生存能力保住。

关于 RAID 5 与 RAID 10 在数据库负载下的更细致取舍，此前一篇数据库独服存储选型实测专门做过对比，可以配合本文的数字一起看。

压测之外：容易踩的三个坑

选对阵列只是第一步，实测过程中还有几个坑值得单独提醒。

其一是不要迷信阵列卡自带缓存的官方标称值。部分阵列卡在顺序写场景会先把写入全部吃进缓存再一次性刷盘，跑分软件会把这当成磁盘成绩。验证方法很简单：把压测时间拉长到 10 分钟以上并观察成绩曲线，如果前 30 秒成绩特别好、之后断崖下跌，说明你测到的很大一部分是缓存而非磁盘本身。

其二是 RAID 5 重建期间的写入会进一步恶化。本文测的是健康态数字，重建窗口里 RAID 5 混合写入通常再打对折，这也是为什么重要业务建议至少 RAID 10 或配置热备盘。降级态和重建态的具体性能衰减幅度，可以看这篇RAID 坏盘降级实测，里面有完整的重建期数据。

其三是别忘了阵列外的备份。RAID 解决的是”坏一块盘不停机”，不是备份——误删、勒索软件、阵列卡故障都可能一次毁掉整个阵列。压测完成后，建议顺手验证一遍备份任务能真实恢复，rsync 或快照方案都可以，恢复演练通过才算数。

结论：按业务负载选阵列，用 fio 验证到手配置

总结一下四种阵列的定位：RAID 0 要性能不要安全，RAID 1 是两盘机的保底方案，RAID 5 用写入性能换容量，RAID 10 用容量换全面均衡。没有”最好的阵列”，只有匹配业务读写比例的阵列。

我的建议是：独服到手先跑本文的四组 fio 命令，拿到自己的 IOPS 和延迟基线再决定业务往哪块盘放；如果你需要选购支持自定义阵列的独立服务器，可以把提供中文技术支持的 Hostease 独立服务器列入对比清单，下单时直接指定阵列级别并要求提供压测截图。想进一步了解独服选型时容易忽略的其他硬件指标，这篇独服价格评估的 5 个指标值得配合阅读。压测数字是死的，业务体验是活的——用 20 分钟的 fio 换一个不返工的存储方案，这笔投入怎么算都划算。