存储协议全景文件存储、块存储、对象存储选型指南一、存储选型的本质二、一张表看懂三类存储三、块存储给服务器一块远程硬盘主要协议一句话选型四、文件存储多台服务器共享同一个目录主要协议分布式文件系统一句话选型五、对象存储HTTP API 存万物核心特点S3 协议一句话选型六、被遗忘的第四类分布式存储内部协议七、存储冗余配比你的数据到底有几条命多副本Replication纠删码Erasure CodingECRAID 经典配比冗余方案速选八、选型速查你的场景该用什么九、速查表把块存储、文件存储、对象存储放一起对比附带存储冗余配比速查。适合需要做技术选型、架构设计、或者单纯想理清这三者区别的读者。一、存储选型的本质存储选型不是在选哪种盘更耐用而是在选数据怎么被读写、谁负责管理文件系统、出故障了怎么恢复。举个例子数据库需要的是裸盘级的直接读写如果你把它挂到 NFS 上中间多了一层文件系统翻译开销外加锁机制拖慢并发io wait 能直接飙到 40% 以上。同样的硬件换成 iSCSI 块存储延迟降到个位数毫秒。选错协议不是加块盘能解决的架构得推倒重来。二、一张表看懂三类存储先给结论。块存储、文件存储、对象存储的本质区别看这张表就够了维度块存储文件存储对象存储抽象层级裸盘/卷Block文件目录树File扁平 Key-Value典型协议iSCSI、FC、NVMe-oF、RBDNFS、SMB/CIFSS3、Swift访问方式直接读写 block 地址POSIX 文件操作open/read/writeHTTP RESTful APIGET/PUT/DELETE谁管文件系统客户端自己格式化存储端提供文件系统没有传统文件系统元数据规模小分区表级别中inode 级别大亿级对象扁平管理一致性强一致取决于实现大多最终一致典型场景数据库、虚拟机磁盘共享目录、家目录、HPC图片/视频/备份/日志/数据湖三种存储不是谁取代谁的关系是不同抽象层级解决不同问题。下面逐个展开。三、块存储给服务器一块远程硬盘块存储的核心逻辑很简单——把远端的物理盘/LUN通过网络暴露成你服务器上的一块裸盘。你的操作系统看到的是一块/dev/sdb可以在上面分区、格式化、创建文件系统跟本地插了一块盘完全一样。因为是裸盘级访问没有中间文件系统层延迟低、吞吐高。代价是你得自己管理这块盘上的一切——格式化、挂载、文件系统、权限。主要协议FCFibre Channel光纤通道SAN 的祖宗级协议。专网专用需要 FC HBA 卡 FC 交换机和以太网物理隔离。极低延迟、极高可靠但成本也极高——一套 FC 交换机够买好几台服务器。现在仍然在金融、电信核心系统里大量使用因为人家要的不是性价比是绝对不能出事。iSCSIInternet Small Computer System Interface把 SCSI 命令封装在 TCP/IP 包里走标准以太网。不需要专用硬件普通万兆网卡就能跑。性能不如 FC但成本低一个数量级。适合中小规模部署。大部分中小企业的虚拟化平台VMware、Proxmox用 iSCSI 就够了。NVMe-oFNVMe over Fabrics为 NVMe SSD 时代设计的远程块协议。传统 SCSI 协议栈是为机械盘设计的命令队列深度只有 32NVMe 原生支持 64K 队列、每队列 64K 命令NVMe-oF 把这个能力搬到了网络上。延迟比 iSCSI 低一个数量级RDMA 模式下微秒级。高性能数据库、AI 训练场景的首选。RBDRADOS Block DeviceCeph软件定义块存储。不需要专用存储硬件在普通 x86 服务器集群上跑 Ceph就能给虚拟机提供块设备。云平台OpenStack、Proxmox的标准块存储方案。一句话选型数据库、虚拟机磁盘 → 块存储。有钱上 FC预算有限上 iSCSI性能敏感上 NVMe-oF自建云平台用 Ceph RBD。四、文件存储多台服务器共享同一个目录文件存储提供的是一个带目录结构的共享文件系统。多台服务器同时挂载同一个 NFS/SMB 导出目录大家看到的文件列表是一样的。优点是方便——不需要管底层怎么存的直接ls、cat、vim就行。缺点是性能不如块存储直接文件系统层的翻译有开销并发锁机制在大量小文件场景下会成为瓶颈。主要协议NFSNetwork File SystemLinux/Unix 生态的标准文件共享协议。v3 是无状态设计简单但缺少强锁机制v4 引入了状态协议、聚合会话、强锁支持安全性也好很多。v4.1 加了 pNFS并行 NFS可以把元数据和数据流分开吞吐能跑到线速。SMB/CIFSServer Message BlockWindows 生态标配。Linux 通过 Samba 服务端可以接入。企业内部的共享盘、部门目录基本都是 SMB。分布式文件系统上面 NFS 和 SMB 都是单机文件存储。数据量超过单机容量时需要分布式文件系统GlusterFS无中心架构没有元数据服务器靠一致性哈希算法定位文件。扩展性好但小文件性能一般。LustreHPC高性能计算场景的王者。元数据和数据分离单目录百万文件无压力。TOP500 超算里大部分存储用的是 Lustre。CephFSCeph 生态的原生文件系统接口底层复用 RADOS。好处是和 RBD、RGW 共享同一套存储集群。一句话选型多台服务器共享读写同一批文件 → 文件存储。Linux 环境 NFSWindows 环境 SMB超算/HPC 用 Lustre自建分布式用 CephFS 或 GlusterFS。五、对象存储HTTP API 存万物对象存储和前面两种完全不是一个思路。没有文件系统、没有目录层级、没有 POSIX 接口——就是一个扁平的 Key-Value 命名空间通过 HTTP RESTful API 访问。每个对象包含三部分数据本身Object Data、元数据Metadata自定义标签、全局唯一 IDObject Key。没有文件夹但可以通过 Key 命名规则模拟层级比如photos/2026/07/img001.jpg。核心特点无限扩展扁平的 Key-Value 结构天然适合横向扩展加节点就行不需要担心目录树膨胀。不适合原地修改对象是不可变的immutable要改一个对象 上传新版本覆盖旧版本。这意味着数据库文件、频繁更新的日志不适合放对象存储。最终一致性大部分对象存储S3 也这样写入后不保证立即可读有几毫秒到几秒的延迟窗口。强一致读需求的场景要多加小心。S3 协议AWS S3 定义了对象存储的行业标准。现在几乎所有对象存储产品——阿里云 OSS、腾讯云 COS、MinIO、Ceph RGW——全部兼容 S3 API。用的就是 HTTP 的那几个动词PUT 上传、GET 下载、DELETE 删除、HEAD 查元数据、LIST 列举。一句话选型图片/视频/备份/归档/日志/数据湖 → 对象存储。别往里面丢数据库文件别频繁小文件覆盖更新那不是它设计的场景。六、被遗忘的第四类分布式存储内部协议上面三类存储是按对应用暴露什么接口分的。但在分布式存储系统内部还有一套节点间通信的协议——不面向应用但决定了这个系统的扩展性和可靠性。RADOSCeph 底层Ceph 的基石。客户端直接通过 CRUSH 算法算出数据应该落在哪个 OSD 上不需要查询元数据服务器。每块数据的放置位置是算出来的不是查表查出来的——这是 Ceph 能扩展到 EB 级别规模的核心原因。CRUSH 算法全称 Controlled Replication Under Scalable Hashing。输入一个对象名 CRUSH map输出一组 OSD 位置。同一个对象名一定算出同一组位置所以不需要中心化的元数据索引。GlusterFS 翻译器栈GlusterFS 把各种功能复制、条带、分布、加密做成可插拔的翻译器数据流经过一层层翻译器处理后落到磁盘上。这个设计有点像 Linux 内核的 I/O 栈——灵活性高但链条太长调试起来想死。这些内部协议日常做选型用不上但要真正理解一个分布式存储为什么性能瓶颈在某处或者故障时数据为什么不丢就必须了解它。七、存储冗余配比你的数据到底有几条命不管用哪种存储协议数据冗余方案的选择都绕不开。这直接决定了两件事实际可用容量是多少以及坏几块盘数据会丢。多副本Replication最直观的冗余方式——每份数据存 N 份。副本数可用容量占比允许同时故障适用场景2 副本50%1 个节点/盘测试环境、非关键数据3 副本33%2 个节点/盘生产环境标准配置4 副本25%3 个节点/盘极少数高安全场景优点是重建速度快——坏了一个副本直接从另一个健康的复制过来就行不需要计算。缺点是空间开销大3 副本意味着 1TB 数据实际占用 3TB。纠删码Erasure CodingEC用计算换空间。把数据切成 M 个数据块计算生成 N 个校验块总共 MN 个块分散存储。只要丢失不超过 N 个块数据就能完整恢复。EC 配比可用容量占比允许丢块数适用场景42 (M4,N2)67%任意 2 块中小规模通用83 (M8,N3)73%任意 3 块大容量冷数据164 (M16,N4)80%任意 4 块超大容量归档EC 的代价是重建时 CPU 开销大——丢了一个块需要读取多个块做矩阵运算恢复。所以一般在冷数据、大容量场景用 EC热数据用多副本。RAID 经典配比单机存储绕不开 RAIDRAID 级别最少盘数可用容量允许坏盘特点RAID 1250%1 块镜像读快写慢最简单RAID 53(n-1)/n1 块单奇偶校验坏一块重建压力大RAID 64(n-2)/n2 块双奇偶校验大容量盘标配RAID 10450%每组最多 1 块先镜像再条带性能和冗余平衡最好一块 16TB 的机械盘重建一次可能要一整天。RAID 5 只剩单盘校验的时候重建途中再坏一块数据就全没了——大容量机械盘强烈建议 RAID 6 而不是 RAID 5。冗余方案速选场景推荐冗余虚拟机系统盘高 IOPS3 副本数据库数据盘RAID 10 或 3 副本对象存储热数据3 副本对象存储冷数据/归档EC 83 或 164备份存储EC 164 甚至更高大容量单机存储RAID 6高性能单机RAID 10八、选型速查你的场景该用什么直接给答案不是各有优劣。你的场景用什么原因MySQL/PostgreSQL 数据库块存储iSCSI/NVMe-oF数据库需要裸盘直接读写NFS 中间层会拖死VMware/Proxmox 虚拟机磁盘块存储iSCSI/Ceph RBD虚拟机镜像就是一块盘部门共享文件夹文件存储SMBWindows 用户直接用 \\ip\share 就能访问AI 训练数据集多机读文件存储NFS/Lustre多台 GPU 机器同时读同一批数据Web 应用图片/视频托管对象存储S3一次上传、CDN 分发、不用管服务器磁盘服务器日志归档对象存储S3日志只写不改、量大、S3 便宜大数据平台数据湖对象存储S3Spark/Hive 可以直接读 S3 上的 Parquet 文件Docker/K8s 持久卷看情况数据库用块共享配置用文件静态资源用对象备份对象存储 EC占用空间小数据冷EC 重建慢无所谓低延迟交易系统块存储NVMe-oF微秒级延迟FC 和 iSCSI 都不够快九、速查表三类存储一句话区分类型一句话块存储给你一块远程硬盘自己格式化自己管文件存储给你一个共享文件夹大家同时用对象存储给你一个无限大的 HTTP 网盘用 API 存和取冗余配比速查你关心的是什么看这个指标实际能用多少空间可用容量占比最多坏几块盘数据不丢允许故障数坏了之后恢复多快多副本快、EC 慢空间利用率最高EC 16480%下一步阅读[存储协议 01] 块存储协议深度拆解iSCSI、FC、NVMe-oF 怎么选[存储协议 02] 文件存储协议深度拆解NFS v3/v4、SMB 实战对比[存储协议 03] 对象存储协议深度拆解S3 API 比你想象的能打[存储协议 04] 纠删码工作原理为什么 42 丢了 2 个还能恢复
【存储】存储协议全景：文件存储、块存储、对象存储选型指南
存储协议全景文件存储、块存储、对象存储选型指南一、存储选型的本质二、一张表看懂三类存储三、块存储给服务器一块远程硬盘主要协议一句话选型四、文件存储多台服务器共享同一个目录主要协议分布式文件系统一句话选型五、对象存储HTTP API 存万物核心特点S3 协议一句话选型六、被遗忘的第四类分布式存储内部协议七、存储冗余配比你的数据到底有几条命多副本Replication纠删码Erasure CodingECRAID 经典配比冗余方案速选八、选型速查你的场景该用什么九、速查表把块存储、文件存储、对象存储放一起对比附带存储冗余配比速查。适合需要做技术选型、架构设计、或者单纯想理清这三者区别的读者。一、存储选型的本质存储选型不是在选哪种盘更耐用而是在选数据怎么被读写、谁负责管理文件系统、出故障了怎么恢复。举个例子数据库需要的是裸盘级的直接读写如果你把它挂到 NFS 上中间多了一层文件系统翻译开销外加锁机制拖慢并发io wait 能直接飙到 40% 以上。同样的硬件换成 iSCSI 块存储延迟降到个位数毫秒。选错协议不是加块盘能解决的架构得推倒重来。二、一张表看懂三类存储先给结论。块存储、文件存储、对象存储的本质区别看这张表就够了维度块存储文件存储对象存储抽象层级裸盘/卷Block文件目录树File扁平 Key-Value典型协议iSCSI、FC、NVMe-oF、RBDNFS、SMB/CIFSS3、Swift访问方式直接读写 block 地址POSIX 文件操作open/read/writeHTTP RESTful APIGET/PUT/DELETE谁管文件系统客户端自己格式化存储端提供文件系统没有传统文件系统元数据规模小分区表级别中inode 级别大亿级对象扁平管理一致性强一致取决于实现大多最终一致典型场景数据库、虚拟机磁盘共享目录、家目录、HPC图片/视频/备份/日志/数据湖三种存储不是谁取代谁的关系是不同抽象层级解决不同问题。下面逐个展开。三、块存储给服务器一块远程硬盘块存储的核心逻辑很简单——把远端的物理盘/LUN通过网络暴露成你服务器上的一块裸盘。你的操作系统看到的是一块/dev/sdb可以在上面分区、格式化、创建文件系统跟本地插了一块盘完全一样。因为是裸盘级访问没有中间文件系统层延迟低、吞吐高。代价是你得自己管理这块盘上的一切——格式化、挂载、文件系统、权限。主要协议FCFibre Channel光纤通道SAN 的祖宗级协议。专网专用需要 FC HBA 卡 FC 交换机和以太网物理隔离。极低延迟、极高可靠但成本也极高——一套 FC 交换机够买好几台服务器。现在仍然在金融、电信核心系统里大量使用因为人家要的不是性价比是绝对不能出事。iSCSIInternet Small Computer System Interface把 SCSI 命令封装在 TCP/IP 包里走标准以太网。不需要专用硬件普通万兆网卡就能跑。性能不如 FC但成本低一个数量级。适合中小规模部署。大部分中小企业的虚拟化平台VMware、Proxmox用 iSCSI 就够了。NVMe-oFNVMe over Fabrics为 NVMe SSD 时代设计的远程块协议。传统 SCSI 协议栈是为机械盘设计的命令队列深度只有 32NVMe 原生支持 64K 队列、每队列 64K 命令NVMe-oF 把这个能力搬到了网络上。延迟比 iSCSI 低一个数量级RDMA 模式下微秒级。高性能数据库、AI 训练场景的首选。RBDRADOS Block DeviceCeph软件定义块存储。不需要专用存储硬件在普通 x86 服务器集群上跑 Ceph就能给虚拟机提供块设备。云平台OpenStack、Proxmox的标准块存储方案。一句话选型数据库、虚拟机磁盘 → 块存储。有钱上 FC预算有限上 iSCSI性能敏感上 NVMe-oF自建云平台用 Ceph RBD。四、文件存储多台服务器共享同一个目录文件存储提供的是一个带目录结构的共享文件系统。多台服务器同时挂载同一个 NFS/SMB 导出目录大家看到的文件列表是一样的。优点是方便——不需要管底层怎么存的直接ls、cat、vim就行。缺点是性能不如块存储直接文件系统层的翻译有开销并发锁机制在大量小文件场景下会成为瓶颈。主要协议NFSNetwork File SystemLinux/Unix 生态的标准文件共享协议。v3 是无状态设计简单但缺少强锁机制v4 引入了状态协议、聚合会话、强锁支持安全性也好很多。v4.1 加了 pNFS并行 NFS可以把元数据和数据流分开吞吐能跑到线速。SMB/CIFSServer Message BlockWindows 生态标配。Linux 通过 Samba 服务端可以接入。企业内部的共享盘、部门目录基本都是 SMB。分布式文件系统上面 NFS 和 SMB 都是单机文件存储。数据量超过单机容量时需要分布式文件系统GlusterFS无中心架构没有元数据服务器靠一致性哈希算法定位文件。扩展性好但小文件性能一般。LustreHPC高性能计算场景的王者。元数据和数据分离单目录百万文件无压力。TOP500 超算里大部分存储用的是 Lustre。CephFSCeph 生态的原生文件系统接口底层复用 RADOS。好处是和 RBD、RGW 共享同一套存储集群。一句话选型多台服务器共享读写同一批文件 → 文件存储。Linux 环境 NFSWindows 环境 SMB超算/HPC 用 Lustre自建分布式用 CephFS 或 GlusterFS。五、对象存储HTTP API 存万物对象存储和前面两种完全不是一个思路。没有文件系统、没有目录层级、没有 POSIX 接口——就是一个扁平的 Key-Value 命名空间通过 HTTP RESTful API 访问。每个对象包含三部分数据本身Object Data、元数据Metadata自定义标签、全局唯一 IDObject Key。没有文件夹但可以通过 Key 命名规则模拟层级比如photos/2026/07/img001.jpg。核心特点无限扩展扁平的 Key-Value 结构天然适合横向扩展加节点就行不需要担心目录树膨胀。不适合原地修改对象是不可变的immutable要改一个对象 上传新版本覆盖旧版本。这意味着数据库文件、频繁更新的日志不适合放对象存储。最终一致性大部分对象存储S3 也这样写入后不保证立即可读有几毫秒到几秒的延迟窗口。强一致读需求的场景要多加小心。S3 协议AWS S3 定义了对象存储的行业标准。现在几乎所有对象存储产品——阿里云 OSS、腾讯云 COS、MinIO、Ceph RGW——全部兼容 S3 API。用的就是 HTTP 的那几个动词PUT 上传、GET 下载、DELETE 删除、HEAD 查元数据、LIST 列举。一句话选型图片/视频/备份/归档/日志/数据湖 → 对象存储。别往里面丢数据库文件别频繁小文件覆盖更新那不是它设计的场景。六、被遗忘的第四类分布式存储内部协议上面三类存储是按对应用暴露什么接口分的。但在分布式存储系统内部还有一套节点间通信的协议——不面向应用但决定了这个系统的扩展性和可靠性。RADOSCeph 底层Ceph 的基石。客户端直接通过 CRUSH 算法算出数据应该落在哪个 OSD 上不需要查询元数据服务器。每块数据的放置位置是算出来的不是查表查出来的——这是 Ceph 能扩展到 EB 级别规模的核心原因。CRUSH 算法全称 Controlled Replication Under Scalable Hashing。输入一个对象名 CRUSH map输出一组 OSD 位置。同一个对象名一定算出同一组位置所以不需要中心化的元数据索引。GlusterFS 翻译器栈GlusterFS 把各种功能复制、条带、分布、加密做成可插拔的翻译器数据流经过一层层翻译器处理后落到磁盘上。这个设计有点像 Linux 内核的 I/O 栈——灵活性高但链条太长调试起来想死。这些内部协议日常做选型用不上但要真正理解一个分布式存储为什么性能瓶颈在某处或者故障时数据为什么不丢就必须了解它。七、存储冗余配比你的数据到底有几条命不管用哪种存储协议数据冗余方案的选择都绕不开。这直接决定了两件事实际可用容量是多少以及坏几块盘数据会丢。多副本Replication最直观的冗余方式——每份数据存 N 份。副本数可用容量占比允许同时故障适用场景2 副本50%1 个节点/盘测试环境、非关键数据3 副本33%2 个节点/盘生产环境标准配置4 副本25%3 个节点/盘极少数高安全场景优点是重建速度快——坏了一个副本直接从另一个健康的复制过来就行不需要计算。缺点是空间开销大3 副本意味着 1TB 数据实际占用 3TB。纠删码Erasure CodingEC用计算换空间。把数据切成 M 个数据块计算生成 N 个校验块总共 MN 个块分散存储。只要丢失不超过 N 个块数据就能完整恢复。EC 配比可用容量占比允许丢块数适用场景42 (M4,N2)67%任意 2 块中小规模通用83 (M8,N3)73%任意 3 块大容量冷数据164 (M16,N4)80%任意 4 块超大容量归档EC 的代价是重建时 CPU 开销大——丢了一个块需要读取多个块做矩阵运算恢复。所以一般在冷数据、大容量场景用 EC热数据用多副本。RAID 经典配比单机存储绕不开 RAIDRAID 级别最少盘数可用容量允许坏盘特点RAID 1250%1 块镜像读快写慢最简单RAID 53(n-1)/n1 块单奇偶校验坏一块重建压力大RAID 64(n-2)/n2 块双奇偶校验大容量盘标配RAID 10450%每组最多 1 块先镜像再条带性能和冗余平衡最好一块 16TB 的机械盘重建一次可能要一整天。RAID 5 只剩单盘校验的时候重建途中再坏一块数据就全没了——大容量机械盘强烈建议 RAID 6 而不是 RAID 5。冗余方案速选场景推荐冗余虚拟机系统盘高 IOPS3 副本数据库数据盘RAID 10 或 3 副本对象存储热数据3 副本对象存储冷数据/归档EC 83 或 164备份存储EC 164 甚至更高大容量单机存储RAID 6高性能单机RAID 10八、选型速查你的场景该用什么直接给答案不是各有优劣。你的场景用什么原因MySQL/PostgreSQL 数据库块存储iSCSI/NVMe-oF数据库需要裸盘直接读写NFS 中间层会拖死VMware/Proxmox 虚拟机磁盘块存储iSCSI/Ceph RBD虚拟机镜像就是一块盘部门共享文件夹文件存储SMBWindows 用户直接用 \\ip\share 就能访问AI 训练数据集多机读文件存储NFS/Lustre多台 GPU 机器同时读同一批数据Web 应用图片/视频托管对象存储S3一次上传、CDN 分发、不用管服务器磁盘服务器日志归档对象存储S3日志只写不改、量大、S3 便宜大数据平台数据湖对象存储S3Spark/Hive 可以直接读 S3 上的 Parquet 文件Docker/K8s 持久卷看情况数据库用块共享配置用文件静态资源用对象备份对象存储 EC占用空间小数据冷EC 重建慢无所谓低延迟交易系统块存储NVMe-oF微秒级延迟FC 和 iSCSI 都不够快九、速查表三类存储一句话区分类型一句话块存储给你一块远程硬盘自己格式化自己管文件存储给你一个共享文件夹大家同时用对象存储给你一个无限大的 HTTP 网盘用 API 存和取冗余配比速查你关心的是什么看这个指标实际能用多少空间可用容量占比最多坏几块盘数据不丢允许故障数坏了之后恢复多快多副本快、EC 慢空间利用率最高EC 16480%下一步阅读[存储协议 01] 块存储协议深度拆解iSCSI、FC、NVMe-oF 怎么选[存储协议 02] 文件存储协议深度拆解NFS v3/v4、SMB 实战对比[存储协议 03] 对象存储协议深度拆解S3 API 比你想象的能打[存储协议 04] 纠删码工作原理为什么 42 丢了 2 个还能恢复
