存储基础到底在讲什么？块/文件/对象、集中式/分布式、DAS/NAS/SAN、RAID 技术一次讲透
我早年在帮一个创业团队做后端存储选型评审的时候，技术负责人指着一块共享文件存储说“这个性能不行，咱们换 SAN 吧”，然后又指了指对象存储说“这个是不是也可以用在我们 MySQL 上”。我当时就意识到，很多人对存储的理解其实停留在“听说过名词”的阶段——块存储、文件存储、对象存储、DAS、NAS、SAN、集中式、分布式、RAID，这些词每个都见过，但真把它们之间的关系和适用场景讲清楚，能现场讲明白的人并不多。
这篇文章就想把存储基础这件事一次性讲透。不管你是刚入行的后端开发、运维工程师，还是正在做架构设计的负责人，只要你的工作跟“数据往哪儿放”沾边，这节内容都值得花十分钟读完。我会把存储领域最核心的分类维度和选型逻辑拆开揉碎，配合我实际踩过的坑和验证过的结论，尽量让你读完就能下手做方案。
1. 数据的第一层分类：块、文件、对象，到底在说什么
很多人第一次接触存储时，最困惑的问题就是：为什么要把存储分成块、文件、对象三种？它们不都是往硬盘里写数据吗？其实这个分类不是按“硬件”分的，而是按“数据怎么被组织和访问”分的。你面向的应用是什么，决定了你该用哪一种形态的存储。
1.1 用一个仓库类比理解三种形态
想象你有一间巨大的仓库，要存东西。
块存储就像是一间被划分成无数“标准格子”的仓库，每个格子有编号，但没有货架，没有标签系统，更没有目录。你往里放东西的时候，得自己记住“我的箱子放在第 3001 到 3040 号格子里”。系统层面看到的就是一串连续的块号，没有任何语义信息。
文件存储就像一间正规的档案室。它有档案柜、有目录、有标签，你可以按照“部门/项目/日期”一层层组织文件。你不需要关心文件被放到了哪个物理位置，只需要告诉系统“我要找 2024 年 1 月的财务报表”，系统就能按目录路径帮你取出来。
对象存储则更像一个全自动化的智能储物柜。每个储物箱都有自己的唯一编号（Key），箱子上可以贴各种标签（Metadata），比如创建时间、文件类型、归属项目。你只需要说“我要取编号为 abc123 的箱子”，柜子就能直接给你，不需要考虑目录层级。
这个类比基本可以对应到三种存储的核心差异：块存储无限扁平、只讲地址；文件存储有层级、有目录；对象存储是扁平寻址、靠 Key 和元数据。
1.2 块存储：最底层、最直接的“标准间”
块存储（Block Storage）把数据切分成固定大小的块（Block），通常以裸设备或逻辑卷的形式呈现给操作系统。它的核心特点是：操作系统看到的是“一块没有文件系统的裸盘”，你需要在上面自己格式化、自己建文件系统，或者直接让数据库软件裸设备管理。
常见的块存储包括服务器内置的 SATA/SAS/NVMe 硬盘、云厂商的云硬盘（类似阿里云 ESSD、AWS EBS）、传统集中式存储划分出来的 LUN，以及大多数分布式存储提供的块接口（比如 Ceph RBD）。
块存储最大的优势是性能稳定、时延低，随机读写能力强。因为它的数据布局最接近物理磁盘，操作系统可以直接控制数据存放位置。代价就是它默认是一个“独占”资源——同一块块存储设备在同一时刻只能挂载给一台服务器（跨主机的文件系统如 OCFS2、GFS2 除外）。我见过很多刚入门的朋友问：“能不能把云硬盘同时挂载到两台服务器上共享？”答案是：原生不能，除非你自己在上层搭建集群文件系统，但那样复杂度会成倍提升。
在实际业务里，块存储最常见的使用场景就是数据库存储盘、虚拟机系统盘、容器引擎的数据卷。凡是需要高性能、低延迟、随机读写的业务，第一选择基本都是块存储。
1.3 文件存储：人类和操作系统最熟悉的组织方式
文件存储（File Storage）以文件和目录组织数据，提供完整的层级命名空间。它对外提供 POSIX 风格的文件接口（open、read、write、close），支持目录、文件锁、文件权限等语义。对于开发者和操作系统来说，这套接口已经有几十年历史，几乎不需要学习成本。
典型的文件存储协议是 NFS（网络文件系统，Linux 生态常用）和 SMB/CIFS（Windows 生态常用）。你日常使用的共享文件夹、公司内部的文件服务器、HPC 高性能计算里的共享目录，基本都是文件存储。
文件存储的最大价值在于“共享”和“易用”。多个客户端可以同时挂载同一个文件系统，通过目录权限控制协作。比如数据分析团队几台机器同时读一份数据集，开发团队共享一个代码目录，这些都是文件存储的典型场景。
文件存储也有自己的短板：一是海量小文件场景下，元数据处理容易成为瓶颈。想象一个目录下有几百万个几 KB 的小文件，每次打开文件都要先查元数据，压力一大响应就慢；二是传统 NAS 设备的扩展能力有限，吞吐量很难做到水平无限扩展。不过像 Lustre、CephFS 这类并行/分布式文件系统已经在很大程度上解决了扩展性问题，但那是另一个层面的话题。
1.4 对象存储：海量非结构化数据的“正确打开方式”
对象存储（Object Storage）是最近十几年发展最快的存储形态。它的核心抽象是“桶（Bucket）”和“对象（Object）”。每个对象由三部分组成：数据本身（Data）、唯一标识（Key）、元数据（Metadata）。典型接口是 S3 兼容 API，比如 PUT、GET、DELETE，或者云厂商的 OSS、COS 接口。
对象存储最大的特点是：命名空间扁平，几乎没有目录层级；寻址方式是通过 HTTP RESTful API 按 Key 直接定位；数据天生分布化，可以轻松扩展到 PB 级甚至 EB 级。它也是目前云基础设施里最便宜、最容易弹性伸缩的存储类型。
但对象存储不是万能的。它不支持真正的随机写，一个对象写进去之后，要么整体覆盖，要么删除重写，不能像块存储那样在任意偏移处修改几个字节。它的访问时延通常在毫秒级甚至几十毫秒级，比本地 NVMe 盘的微秒级时延差好几个数量级。所以数据库这类需要频繁随机读写的业务，绝不适合跑在对象存储上。
我在实际项目里主要用对象存储来存三类数据：静态资源（图片、视频、前端打包产物）、备份归档（数据库备份、日志归档）、大数据/AI 数据集（训练样本、特征文件）。这些数据共同的特点是：量大、不太需要修改、需要长期保存、希望通过 HTTP 方式随时访问。
1.5 三种存储怎么选：指标与场景对照
为了帮你快速建立判断框架，我把三种存储形态的核心差异整理成一张表。
| 比较维度 | 块存储 | 文件存储 | 对象存储 |
|---|---|---|---|
| 最小数据单元 | 固定大小的块 | 文件 | 对象 |
| 寻址方式 | 块号（LBA） | 目录路径 | HTTP Key |
| 访问接口 | SCSI/NVMe/虚拟磁盘 | NFS/SMB/POSIX | S3/OSS/COS API |
| 随机读写 | 优秀 | 一般 | 不支持（只能整对象写） |
| 共享能力 | 差（只能单机挂载） | 好（多客户端共享） | 极好（全网访问） |
| 扩展性 | 水平扩展需要额外方案 | 受限于元数据/设备 | 天然分布化，近乎无限 |
| 典型场景 | 数据库、虚拟机盘 | 共享文档、HPC、媒体素材 | 静态资源、备份、大数据 |
这里再补充一个最常用的判断口诀：数据库和虚拟机的系统盘选块存储；多台机器共享目录选文件存储；海量非结构化数据、备份归档、静态资源选对象存储。实际业务里往往是三种存储混合使用，不要指望一种形态解决所有问题。
2. 集中式还是分布式：架构层面的第一场仗
搞定了数据形态，下一步要考虑的是系统架构：这一堆硬盘，是集中到一起由一台专用设备管理，还是分散到一堆普通服务器里靠软件协同管理？这就是集中式存储和分布式存储的分歧点。
2.1 集中式存储：专用设备的高可靠性堡垒
集中式存储，通俗讲就是一台专业的“存储机器”——磁盘阵列或存储阵列。我们常听的传统存储厂商产品（类似中高端存储阵列）就是典型代表。它们用专门的硬件控制器、专用芯片、双控甚至多控架构，提供企业级的高可靠性和高性能。
集中式存储的典型特征是：硬件和软件紧密耦合，厂商已经调优好了整套方案。设备内部实现了 RAID 保护、缓存加速、自动分层、快照、远程复制、双活容灾等高级功能。你不需要自己操心底层实现，只需要在管理界面里划卷（创建 LUN）分配给服务器使用。
优点非常明显：性能稳定、功能完善、可靠性高。像银行核心系统、运营商计费系统这些对延迟和稳定性要求极高的场景，至今仍然大量使用集中式存储。缺点是贵，而且横向扩展能力有限——当容量需求从几十 TB 涨到几个 PB，集中式存储的容量扩展往往受限于控制器的性能和机柜空间，需要提前规划好规模。
2.2 分布式存储：软件定义下的横向扩展利器
分布式存储的思路完全相反：用大量通用服务器（x86 服务器加上内置硬盘），通过分布式软件把它们组织成一个统一的存储池。代表技术有 Ceph、MinIO、HDFS、Lustre 等。
核心机制是数据打散存储：文件或对象被切成多个数据分片，按一定策略（副本数或纠删码）分布到不同节点上。任何一个节点坏了，数据依然可以从其他节点的副本/校验块恢复回来。容量不够了，加新服务器就能线性扩容，性能也会随之提升。
我实际用过 Ceph 做私有云底座的块存储，也用过 MinIO 做对象存储，这种架构的吸引力非常直接：成本低、扩展方便、不绑定厂商硬件。但代价是软件栈复杂度高，部署和运维难度远高于集中式存储。你可能需要专门的 SRE 团队来维护监控、故障恢复、网络调优。如果你的团队没有存储方向的专职人力，建议慎重。
2.3 架构选型：几个关键问题帮你敲定方向
集中式还是分布式，没有绝对的好坏，完全看场景。我总结了几个每次做选型必问的问题，基本能帮你理清方向。
第一，数据量预期有多大？如果未来 3 到 5 年的数据量大概率不会超过几十 TB，集中式小型存储阵列完全够用，没必要上分布式。如果业务在线数据要奔着 PB 级别去，分布式基本是你唯一的选择。
第二，性能要求有多苛刻？集中式存储通常能做到亚毫秒级稳定时延，适合交易类系统。分布式存储受网络调度影响，性能波动相对大一些，更适合对时延不极端敏感的场景。
第三，预算和运维团队情况如何？集中式存储采购成本高，但运营成本低，厂商帮你兜底。分布式存储硬件成本低，但人力成本高，你需要有足够强的内部团队。
第四，业务是否在云环境里？如果直接用云厂商的云硬盘、文件存储、对象存储，那其实你已经被“云基础设施”默认接到了分布式存储生态里了。云厂商底层基本都是分布式架构，选云产品时你个人不需要再纠结集中式还是分布式。
2.4 顺带聊一下云基础设施机制
现在很多存储方案其实都是在云环境里落地的。云基础设施机制简单理解就是云环境的基础构件块——针对计算、存储、网络这三个基本盘设计的能力单元。存储就是其中的核心构件之一。
你看到的云硬盘、云文件存储、对象存储，本质上就是把传统存储能力“产品化”后的云构件。块存储对应虚拟机的系统盘和数据盘，文件存储面向需要共享文件系统的应用，对象存储面向海量数据资产。理解了上面这些分类，再去看云厂商的控制台，你会发现各家的产品逻辑其实是高度一致的。这也是这篇存储基础文章能直接落地到云端选型的原因。
3. DAS、NAS、SAN：三种连接和共享方式，别再混淆了
接下来要讲的三个概念，很多人容易和上面的“块/文件/对象”搞混。DAS、NAS、SAN 不是数据形态的另一种分类，而是描述“存储设备怎么连接到计算节点、以什么方式共享”的架构模式。
3.1 DAS：最朴素直连式存储
DAS（Direct Attached Storage，直连式存储）就是存储设备直接连接到一台服务器，本地独占访问。最典型的例子：服务器机箱里的 SATA/SAS 硬盘、外接一张 RAID 卡带着一堆盘柜、通过 SAS 线连接的 JBOD 扩展柜。
DAS 的优点就是简单、成本低、时延最短——数据不需要经过网络协议，直接走本地总线。缺点同样明显：不能多机共享，磁盘资源固定在一台机器上，管理上也比较分散。如果你有一堆服务器，每台都用 DAS，那容量和性能资源就无法在多台机器之间灵活调度。
DAS 目前仍然大量存在于单机数据库、大数据节点本地盘、边缘计算节点等场景。很多高性能数据库单机方案，其实自己用 NVMe 盘做 RAID 就是典型的 DAS 架构。
3.2 NAS：面向文件共享的网络存储
NAS（Network Attached Storage，网络附加存储）的本质是把存储设备通过网络协议（NFS/SMB）共享给多台服务器或终端使用。NAS 设备本身是一台带有文件系统管理能力的专用服务器，对外提供的是文件访问接口。
你家里用的群晖，公司里的文件服务器，云计算里的文件存储服务，都是 NAS 模式。它的核心价值是“共享”和“易用”——多台机器可以同时读写同一个目录，文件权限管理简单直观。
NAS 的短板在于文件协议栈有一定的网络开销，性能上限不如 SAN 这种块级访问。不过随着万兆网络普及和 NFS v4 协议的优化，中高端的 NAS 在虚拟化和容器场景里的表现已经相当能打。我见过不少私有云平台直接用高性能 NFS 存储做虚拟化数据卷和容器 PV，效果不差。
3.3 SAN：把块设备“拉到服务器面前”
SAN（Storage Area Network，存储区域网络）是一条专门用于存储访问的“专用网络”，它把存储阵列上的块设备（LUN）通过网络映射给多台服务器。服务器看到的是一个裸盘（块设备），和本地磁盘一样可以格式化、做文件系统。
SAN 的访问协议主要有三种：FC（光纤通道）、iSCSI（基于 TCP/IP 的 SCSI 协议）、NVMe-oF（NVMe over Fabrics）。FC 是传统企业存储的主流选择，性能好但需要独立的光纤交换机，成本高；iSCSI 可以复用现有以太网，部署成本低；NVMe-oF 则是面向全闪存时代的新方案，延迟可以做到跟本地 NVMe 盘相当。
SAN 最大的价值是“共享块设备”。虽然单块 LUN 默认也只能给一台服务器用，但在 SAN 之上可以构建多节点高可用集群——比如 Oracle RAC、VMware vSphere HA、Windows 故障转移集群，它们需要多个服务器都能访问到同一份数据存储。
3.4 对比与趋势：超融合和软件定义存储来了
用一张表把 DAS、NAS、SAN 拉齐对比一下：
| 比较维度 | DAS | NAS | SAN |
|---|---|---|---|
| 共享单元 | 无（独占） | 文件系统 | 块设备（LUN） |
| 访问协议 | 本地总线 | NFS/SMB | FC/iSCSI/NVMe-oF |
| 部署复杂度 | 极低 | 低 | 高 |
| 性能 | 最高（无网络开销） | 一般（网络+协议开销） | 高（专用/高速网络） |
| 扩展方式 | 难扩展 | 中低端受限，高端可扩展 | 扩展能力强 |
| 典型场景 | 单机数据库、本地盘集群 | 文件共享、虚拟化存储 | 高可用数据库、集群文件系统底座 |
还需要点名一个趋势：超融合（HCI）和软件定义存储（SDS）正在模糊这些传统边界。超融合说白了就是把计算和分布式存储打包在同一批服务器里，用分布式软件实现类似 SAN 的块服务，但又不用买专用的存储阵列和光纤交换机。现在很多新项目的存储选型，不再执着于“上 NAS 还是上 SAN”，而是直接评估“买传统存储阵列还是上超融合/分布式存储”。
4. RAID 技术：性能与可靠性的底层舞蹈
聊完架构模式和连接方式，终于轮到底层物理盘层面的技术——RAID。RAID 全称 Redundant Array of Independent Disks，独立磁盘冗余阵列。它存在的根本原因有两个：单块硬盘的可靠性不够，单块硬盘的性能不够。RAID 把多块物理盘组合成一个逻辑盘，换取更高的性能和更好的容错能力。
4.1 RAID 的三板斧：条带化、镜像、校验
要理解 RAID，只需要抓住三个核心手段。
条带化（Striping）是把数据切成固定大小的块，依次分布到多块硬盘上。比如写一个 128KB 的数据，切成 16 个 8KB 的条带，分别写到 16 块盘上，写性能直接翻了 16 倍（理想情况下）。条带化就是拿并行换速度。
镜像（Mirroring）是把数据同时写到两块或更多块盘上，任何一块盘坏了，另一块盘上还有完整副本。镜像的代价是写放大——写一份数据要产生多份写操作，可用容量也只有总容量的一半。
校验（Parity）是一种更“聪明”的冗余方式。它不完整复制数据，而是按位运算生成校验信息，当一块盘损坏时，可以用其他盘的数据和校验信息反推出缺失的数据。校验有效节省了容量，但代价是写入时需要额外的计算负担，性能损耗比镜像更大。
4.2 常用 RAID 级别速查与原理
实际项目里，绝大多数场景只用到 RAID 0、RAID 1、RAID 5、RAID 6、RAID 10 这五种级别。
RAID 0 就是纯条带化，容量 = N 块盘容量之和，理论上性能最好，但没有任何冗余，任一块盘坏了整组数据全丢。我一般不建议在生产环境用 RAID 0，除非你完全不在乎数据丢失，比如临时缓存或者可以从上游重建的数据。
RAID 1 是纯镜像，至少两块盘，可用容量只有一半，写入性能略有下降（要同时写两份），读取性能可以提升（可以从多副本同时读）。它最突出的优势是恢复速度快，坏了一块盘，直接拆下来换新盘重建即可，因为数据是完整复制的，不需要做校验计算。
RAID 5 是条带化加分布式校验，至少三块盘，允许坏一块，可用容量 = N-1。它兼顾了容量利用率和可靠性，随机读性能和 RAID 0 接近，但写入有额外开销。在数据库这类写密集场景下，RAID 5 的写性能一直是个软肋。
RAID 6 在 RAID 5 基础上多了一份校验信息，至少四块盘，允许同时坏两块，可用容量 = N-2。它对大容量磁盘特别友好，因为单盘重建时间很长，在这期间如果再坏一块盘，RAID 5 就直接玩完，RAID 6 还能扛住。
RAID 10 是先做镜像再做条带化，至少四块盘，可用容量 = N/2，允许不同镜像组里各坏一块盘。它既有镜像的快速恢复能力，又有条带化的高性能，是数据库场景最常见的配置。代价就是容量成本高。
| RAID 级别 | 最少盘数 | 可用容量 | 允许故障盘数 | 写入代价 | 典型场景 |
|---|---|---|---|---|---|
| RAID 0 | 2 | N | 0 | 无 | 临时数据、缓存 |
| RAID 1 | 2 | N/2 | 1 | 1 份写变 2 份 | 系统盘、日志盘 |
| RAID 5 | 3 | N-1 | 1 | 需计算校验 | 文件存储、备份 |
| RAID 6 | 4 | N-2 | 2 | 双重校验 | 大容量存储、归档 |
| RAID 10 | 4 | N/2 | 每个镜像组 1 块 | 1 份写变 2 份 | 数据库、虚拟化 |
4.3 RAID 计算的几个核心公式
做存储容量估算的时候，最常用的就是“可用容量 = 单盘容量 × 盘数 × 系数”的变形。比如你买了 6 块 4TB 的盘做 RAID 5，可用容量是 4 × (6-1) = 20TB，不是 24TB。RAID 6 就是 16TB，RAID 10 是 12TB。这个如果预估错了，业务还没上线就得告急。
性能估算里更关键的是“写惩罚”概念。不同 RAID 级别做一次逻辑写操作时，底层物理磁盘实际发生的 I/O 次数不同：RAID 0 写惩罚是 1，RAID 1 和 RAID 10 是 2，RAID 5 是 4，RAID 6 是 6。换句话说，如果你需要数据库达到 10000 随机写 IOPS，用 RAID 5 的话，底层磁盘实际要承担接近 40000 IOPS 的压力。这也是强调数据库别用 RAID 5 的原因之一。
举个具体例子：假设你有一组 8 块 2.5 英寸 10K RPM SAS 磁盘，单盘随机写 IOPS 约 150。做成 RAID 10，总写入能力大致等于 (150 × 8) / 2 = 600 IOPS。做成 RAID 5，总写入能力大致等于 (150 × 8) / 4 = 300 IOPS。性能差距很明显，尤其是数据库这种对写入要求高的业务。
4.4 RAID 实践避坑提醒
我把这些年做存储踩过的坑整理成几条建议，每一条都是真金白银换来的。
RAID 5 慎用于大容量磁盘。单盘容量超过 2TB 以后，RAID 5 重建时间可能长达十几小时甚至数天，重建期间阵列处于“降级”状态，一块盘再坏就数据全毁。10TB 级别的盘，我基本都是建议用 RAID 6 或者 RAID 10。
写缓存必须有掉电保护。很多硬件 RAID 卡和存储阵列都带写缓存（Write Cache），性能提升非常明显，但如果没有超级电容或电池保护，突然断电可能导致缓存里的数据丢失。我见过不少团队买了便宜的 RAID 卡，没配掉电保护模块，一次断电就丢数据。
做 RAID 前确认所有盘是同型号同批次。混用不同速度、不同厂商的盘，性能会按最差的那块盘对齐，而且后续故障率分布也不均匀。阵列里的盘尽量一次买齐，保留备用盘放在库房里。
热备盘不是装饰品。RAID 5 或 RAID 6 阵列最好额外配置一块热备盘。一旦某块盘故障，阵列会自动切换热备盘开始重建，不需要等运维人员半夜爬起来换盘。热备盘换来的这段“无人值守窗口”往往能挽回一场事故。
最后必须强调：RAID 不是备份。RAID 解决的是单盘硬件故障问题，它不能防止误删除、勒索病毒、控制器故障、机房火灾。很多团队以为上了 RAID 就万事大吉，结果被 rm -rf 一场事故打回原形。真正可靠的数据保护，永远是 RAID 加备份加容灾的多层组合。
5. 综合选型实战：当一个电商平台需要设计后端存储方案
理论基础说完了，最后用我实际帮一个中等规模电商平台做存储方案的经历，把这些知识串起来走一遍。这个平台规模不算大，日订单量 10 万级别，但组件不少：MySQL 数据库、Redis 缓存、Elasticsearch 检索、图片和静态资源、日志采集、大数据分析。
5.1 需求拆解与存储映射
先把各个组件的存储需求拆开来看。MySQL 的数据文件需要高性能随机读写，这是最典型的块存储场景，我选了 NVMe 云硬盘，做了 RAID 1 级别的冗余（云厂商底层通常已经做过三副本，这里不再自己做 RAID，这个概念下面单独说）。
Elasticsearch 也是块存储更合适，因为 ES 底层对磁盘 I/O 的要求很高，而且对延迟敏感。同样用高性能云硬盘。
图片、视频、前端静态资源这类文件，量大但几乎不修改，访问非常频繁，放到对象存储里最合理。我做了一个对象存储桶加 CDN 加速的组合，成本比用文件存储低了一大截。
日志数据是持续追加的流式数据，可以先写消息队列，再异步落地到对象存储做冷数据归档。分析平台需要跑批处理，直接把数据放到兼容 S3 协议的对象存储或者分布式文件存储里，计算框架直接读。
Redis 的持久化文件和容器镜像这些临时文件，用本地盘也就是 DAS 模式就够了，坏了可以从主节点重建或重新拉取。
5.2 云上存储和自建存储的选择逻辑
这个平台当时在公有云上，所以选型变成了从云厂商产品线里挑：云硬盘对应块存储，文件存储 NAS 服务对应文件存储，对象存储对应对象存储。云厂商底层其实已经把集中式和分布式都做完了，用户感受到的就是“我可以按量购买的存储构件”。
这里特别提醒一点：在云上使用云硬盘时，不要在实例内部再自己做 RAID。因为云硬盘底层已经做了多副本冗余，你在虚拟机里做 RAID 1 不仅浪费一半容量，还增加了一层虚拟化层的复杂操作。这一点和物理机场景截然不同，很多人带着物理机时代的习惯上云，白白浪费了成本。
5.3 一个完整的存储决策四步法
结合这个案例，我把存储选型的判断逻辑整理成一套四步法，你可以直接拿去当 checklist 用。
第一步，确定每个组件的数据形态：是随机读写的库文件，还是共享目录，还是海量小文件？这决定了选块、文件还是对象。
第二步，确定架构模式：数据量是否大到单机存储搞不定？是否需要水平扩展？这决定了集中式还是分布式，以及要不要用云存储服务。
第三步，确定接入方式：这台服务器是需要直连盘、走网络文件共享，还是需要共享块设备做集群？这决定了是 DAS、NAS 还是 SAN。
第四步，确定底层保护级别：在物理盘层面是 RAID 5、RAID 6 还是 RAID 10？在逻辑层面是依赖副本、快照还是远程复制？别忘了在 RAID 之上叠加备份。
5.4 常见误解和选型误区
最后把我在评审方案时常遇到的几个误区总结一下，看到这里你可以自我对照一遍。
误区一：认为 NAS 一定比 SAN 性能差。这种说法放到十年前大致成立，但现在万兆以太网和高性能 NVMe 存储普及后，中高端 NAS 在大多数业务场景下的性能已经够用，而且部署和维护成本远低于 FC SAN。
误区二：认为对象存储可以替代文件存储。虽然对象存储的类型和接口越来越丰富，但文件存储的 POSIX 语义、目录操作、随机写入能力是对象存储不具备的。很多传统应用根本没法改成 HTTP API 访问方式。
误区三：只在 RAID 和备份之间二选一。这是两条完全不同的防线，RAID 防硬件故障，备份防逻辑错误。一个合格的存储方案必须两者兼有。
误区四：忽略重建窗口期的风险。很多人设计 RAID 时只算了“允许坏几块盘”，却没算“最坏情况下需要多长时间恢复”。大容量磁盘重建耗时极长，这段时间阵列一直在降级运行，性能受影响不说，风险还很高。规划一定要把重建时间纳入考虑。
6. 最后几句实在话
存储这块内容，刚接触会觉得知识点很碎：块、文件、对象，DAS、NAS、SAN，集中式、分布式，RAID 0/1/5/6/10，每个概念都有大量细节，很容易越看越乱。但我做了这么多年存储选型，最大的体会是：这些概念之间是有清晰逻辑链的，从数据形态到整体架构，到接入方式，最后到底层保护，一层层递进。只要建立好这个框架，遇到具体方案时按这条线去推，基本不会跑偏。
我个人在实际操作中的另一个体会是：存储选型没有“最佳方案”，只有“最适合当前阶段的方案”。每个团队的业务规模、预算、人员能力都不一样，方案一定要综合权衡。不要为了技术上的“先进性”去盲目上分布式，也不要因为“听人说 SAN 稳定”就不管三七二十一套方案。先搞清楚你手里的是什么数据，再去匹配对应的存储形态，这才是正确的打开方式。
最后送大家一个小建议：如果你想真正吃透这些存储基础，光看文章是不够的，找一台带几块空闲磁盘的服务器，亲手组一次 RAID，搭一个小型 NAS 或分布式存储集群，用数据库压一压性能，体验一遍故障处理流程。踩过坑之后，你对存储的理解一定会比读十篇文章更深刻。
