独立服务器RAID阵列坏盘怎么办：fio实测降级与重建期的性能真相

很多站长在独立服务器（整机租用的物理服务器）上跑了两三年，总会在某个凌晨收到阵列卡告警：一块盘黄了。坏盘后降级状态和重建期间业务还能不能扛？这篇文章用 fio（Flexible I/O Tester，Linux 下最常用的磁盘压测工具）在同一台机器、同一批盘上，把 RAID 0/1/5/10 的健康、降级、重建三个阶段挨个压一遍，用数据说清楚坏盘窗口期的性能真相，帮助你选阵列时把这份风险算进去。与常见的”四种 RAID 参数对比”帖不同，本文重点放在故障态——因为决定业务会不会出事的，恰恰是坏盘之后的那几个小时。

测试环境与方法说明

测试机的配置在同类独立服务器里比较有代表性：

CPU：双路 16 核，主频 2.1GHz
内存：64GB DDR4 ECC
磁盘：4 块 480GB 企业级 SATA SSD，同一批次
阵列卡：带 2GB 缓存及缓存保护（BBU）的独立 RAID 卡
系统：Debian 12，fio 版本 3.28

阵列卡刷配置的过程这里不展开，唯一要提醒的是：每换一种阵列级别都必须重建逻辑盘并重新装系统，别指望在线切换。盘、卡、系统、fio 参数全部一致，只有阵列级别不同，数据才有可比性。

压测统一用下面这组 fio 命令，分别对应四种典型业务负载（先看顺序读的完整参数结构，其余三个只换 --rw 与 --bs）：

# 顺序读（大文件下载、视频站）
fio --name=seqread --rw=read --bs=1M --numjobs=1 \
    --iodepth=32 --direct=1 --size=8G --runtime=60 \
    --time_based --group_reporting

# 顺序写（备份、上传落盘）：--rw=write，其余参数同上
# 4K 随机读（数据库读密集）：--rw=randread --bs=4k --numjobs=4
# 4K 随机写（高写入数据库、消息队列）：--rw=randwrite --bs=4k --numjobs=4

所有测试都加了 --direct=1 绕过系统缓存，每组跑 60 秒取稳定值，测前都对逻辑盘做过一次全盘写入预热，避免新盘首次写入掉速干扰结果。

四种阵列的实测数据

先给结论汇总，再逐项拆开看。以下数据为 60 秒稳定段的均值：

顺序读写吞吐（MB/s）

RAID 0（4 盘条带）：读 1930 MB/s，写 1810 MB/s
RAID 10（4 盘镜像条带）：读 1720 MB/s，写 880 MB/s
RAID 5（4 盘校验）：读 1580 MB/s，写 610 MB/s
RAID 1（双盘镜像，另两盘冷备）：读 870 MB/s，写 840 MB/s

RAID 0 的吞吐几乎就是单盘的 4 倍，条带并行读写的收益非常直白。RAID 10 的读接近 RAID 0——因为镜像的两份数据都可以参与读——但写只有一半左右，每个写操作要落到两块盘上。RAID 5 的写最吃亏，610 MB/s 意味着每写一笔数据阵列卡都要额外算一次校验并改写校验盘，即使有 2GB 缓存兜着，写入惩罚依然存在。

4K 随机读写 IOPS

RAID 0：随机读 218000 IOPS，随机写 176000 IOPS
RAID 10：随机读 226000 IOPS，随机写 91000 IOPS
RAID 5：随机读 214000 IOPS，随机写 47000 IOPS
RAID 1：随机读 121000 IOPS，随机写 114000 IOPS

随机读一项，RAID 0 / 5 / 10 都在 21 万 IOPS 以上，差距不大——这是阵列卡缓存和多盘并行共同作用的结果，瓶颈已顶到卡的处理能力。真正拉开差距的是随机写：RAID 10 的 91000 IOPS 大约是 RAID 5 的两倍，RAID 5 的 47000 IOPS 折算下来不到 200MB/s 的小块写入能力，拿它跑写入密集的 MySQL 或 Redis 持久化，延迟会明显感知到。

降级状态与重建期间：坏盘窗口期的真相

只看健康状态的数据是不够的——坏盘之后的世界才是本文的主菜。我额外补测了降级与重建两组极端情况，先看直观对比图，再拆开讲细节。

RAID 5 拔掉一块盘进入降级状态后，随机写从 47000 IOPS 直接掉到 11000 IOPS，顺序写也从 610 MB/s 跌到约 190 MB/s——每笔读都要实时重算校验，阵列卡 CPU 成为新瓶颈。
4 盘 RAID 5 重建期间（约 42 分钟完成），前台随机写长期徘徊在 8000 IOPS 上下，如果这时正好赶上业务高峰，数据库响应时间会成倍放大。
RAID 10 的降级表现好得多：坏一块盘只影响一个镜像对，剩余镜像继续扛住全部负载，降级后随机写仍有 88000 IOPS 左右，业务侧几乎无感。
RAID 1 同理，单盘故障后另一块盘独立承载全部读写，性能与健康态基本一致；RAID 0 则没有”降级”这个概念——坏一块盘，数据直接全灭。

把这些数字换算成业务语言：如果你的 MySQL 主库随机写平时就在 10000 IOPS 上下，RAID 5 一旦降级，磁盘队列立刻堆满，iostat 里的 await 从不到 1 毫秒飙到几十毫秒，前端表现为整站变慢；同样的事故发生在 RAID 10 上，监控曲线几乎是一条平线。很多老站长宁可少一半容量也坚持 RAID 10，不是没算过容量账，是算过故障账。

四种阵列分别适合什么业务

数据看完，落到选型上就是一句话：先看业务写入特征和故障承受力，再看容量预算。

RAID 0：只适合可随时重建的临时数据。 4 倍吞吐和最高的 IOPS 很诱人，但任何一块盘故障，整组数据全灭。它适合跑临时转码、爬虫中间结果、可重新生成的缓存层。把正式业务数据放在 RAID 0 上，等于把可靠性压在任何一块盘不出事上，长期运行的风险敞口并不小。

RAID 1：小容量、重安全的轻负载。 双盘镜像容量减半，吞吐只有单盘水平，但换来的是最简单可靠的冗余，重建快、降级无感。个人站、企业官网、轻量应用，2 块盘的 RAID 1 完全够用，剩下的预算加到内存上往往更划算。

RAID 5：读多写少的文件与静态内容。 4 盘 RAID 5 可用容量 75%，空间效率最高，随机读也不差。但它要同时背上写入惩罚和降级风险两笔账——坏盘后随机写掉到 11000 IOPS、重建期间进一步跌到 8000 IOPS，窗口期短则半小时、长则半天。它适合图片服务器、静态资源、备份归档这类读密集负载；不要拿它承载高写入的数据库。

RAID 10：数据库与混合负载的首选。 容量减半换来的是写性能和降级可靠性的双重保障，随机写是 RAID 5 的两倍，坏盘后业务几乎无感。跑 MySQL、PostgreSQL、MongoDB 这类既有随机读又有大量随机写的业务，4 盘起步的 RAID 10 是稳妥的默认解。如果整机方案还没定，这篇独立服务器性价比评估指南里的五个量化指标可以直接套用，其中存储子系统的分数就应该用本节这类 IOPS 数据来打。

压测与选型的几点建议

最后给几条这次压测沉淀下来的实操经验：

先定业务负载再定阵列级别：写入占比超过三成的业务直接排除 RAID 5，这笔账在 IOPS 上会算得很清楚。
阵列卡的缓存和缓存保护（BBU/超级电容）对 RAID 5 写性能影响巨大，同级别阵列下没有缓存的卡，RAID 5 随机写可能再砍一半。
交付后自己用 fio 复测一遍：交付当天跑一轮本文的命令留档基线，性能异常时就有数据可比，这比事后翻商家页面争论有用得多。
监控阵列降级状态：定期检查阵列卡后台的磁盘健康与降级告警，RAID 5 降级期间是最脆弱的窗口，拖得越久风险越大。
坏盘后先评估再动手：业务高峰遇到降级时，可先限制写入流量或暂停从库同步，等低峰期再触发重建，避免重建 I/O 与业务 I/O 互相踩踏。

选机器的时候别只盯着 CPU 和内存报价，像 Hostease 这类商家的独立服务器在阵列配置上通常允许自选 RAID 级别，下单前把阵列选型、主机速度测试实录里提到的压测口径这些前置决策做在装机之前；配好之后再想改阵列级别，重建的时间成本和数据迁移风险都要高得多。整机横向对比可再看这篇独立服务器租用排行。

总结

同一台 4 盘 SSD 独立服务器，坏盘前后的表现差距比多数人想象的大：RAID 0 坏盘即数据全灭，RAID 1 降级无感但性能平平，RAID 5 降级后随机写只剩四分之一、重建期间还会进一步下探，RAID 10 则用一半容量买到坏盘窗口期的从容——降级后随机写仍有 88000 IOPS。如果你的业务是数据库或读写混合负载，推荐直接上 RAID 10；如果是静态内容与文件服务，RAID 5 的空间效率更有吸引力，但要把降级窗口的运维预案提前写好。拿不准的时候，用本文的 fio 命令在自己机器上压一轮，数据会替你做决定。