将规律从不同类型的分布式系统（如数据库、存储、消息队列）中抽象出来是困难的。这种上层的理论和经验总结，也常使初学者在阅读《DDIA》这类书籍时感到困惑——一旦脱离了具体的应用场景，理解就容易变得模糊。因此，明确研究背景和内容是深入探讨设计思路与技术方法的前提。
本节将重点剖析以下内容：
- 分布式存储系统的常见产品形态（对象存储、块存储、文件存储等）。
- 分布式存储系统实现中的核心组件（如存储引擎、元数据节点与管理节点）。
- 针对一个假想需求，共同完成一份初步的技术选型CheckList。
本节目标：
- 面向分布式存储开发者：为后续深入讨论系统设计奠定基础。
- 面向分布式存储用户：理解不同存储产品的优势与局限所在。
- 面向其他技术背景读者（如分布式数据库）：提供一个综述视角，了解分布式存储工程师的思维方式。
分布式存储系统形态
随着大规模应用和云服务的发展，分布式存储自然演化出几种主流的产品形态，主要包括对象存储、块存储和文件系统存储。
对象存储 (Object Storage)
谈及对象存储，Amazon S3 已成为事实上的标准接口。其全称 Simple Storage Service 中的 “Simple” 体现在何处？
设想一个大型互联网公司存储海量用户媒体数据（规模可能达 EiB 级别），选择对象存储的理由如下：
简单之处：线性扩展与性能
- 集群容量从 1TiB 扩展到 1EiB，读写延迟数量级基本保持稳定（约百毫秒级）。
- 集群的 IOPS 和带宽能够随数据量和机器资源线性增长。
- 扩缩容操作简便，主要依赖于提供或回收机器资源。
此类业务通常不纠结于几百毫秒的延迟优化，但对集群吞吐量及其线性增长能力要求极高，需要支撑百万级并发。存储研发的重点在于保障系统性能的线性扩展。
简单之处：操作语义简洁
这里的“语义简洁”是相对于 POSIX 文件系统的复杂性而言。此类业务通常放宽对 POSIX 原子性的严格要求，核心支持 PUT（上传）、GET（下载）、DELETE（删除）等操作。资源的上传下载可直接通过 HTTP 协议在互联网上进行。
此外，对象存储中的对象名称是平铺的，使用 “/” 符号仅是为了模拟文件夹语义，本质上是一种 Key-Value 结构，将完整的对象名视为一个 Key。例如，对于 Bucket b1 中的对象 dir1/dir2/dir3/1.jpg，简单的 S3 实现会直接将整个路径字符串作为一个 Key。
简单之处：牺牲了文件夹语义与相关性能
这种平铺的设计带来了优异的扩展性和性能，代价是业务不能重度依赖目录操作，如频繁的列表（ls）、重命名（rename）、移动（mv）等，且部分操作不保证原子性。
用户使用工具对目录执行 du（查看占用空间）或 ls 操作，其原理是基于 Key 前缀进行扫描来模拟文件夹语义。在性能和计算开销上，这与原生支持文件树数据结构的分布式文件系统不可同日而语。这也是为何云厂商常将 S3 操作分为不同类别（如 A 类、B 类）并差异化定价的原因之一。
简单之处：不支持覆盖写
对象一旦成功写入，即成为不可变的（immutable）。用户无法对对象中的某个范围（range）进行覆盖写，这是区别于文件系统的一个重要特性。
适用场景
S3 对象存储最适合存储海量媒体数据、AI 训练中读写大量检查点（checkpoint），或用于备份归档。这些场景对集群的可扩展性、吞吐量要求极高，但对 IO 延迟没有极端要求。
当业务需要覆盖写、大量原子性的复制/重命名操作，或强依赖于文件夹操作时，平坦结构的对象存储就无法满足需求了。（尽管有厂商支持部分文件树语义的对象存储，但其更接近支持部分 POSIX 语义的文件存储）。
此外，在多数据中心场景下考虑多活写入的一致性时，对象存储通常采用简单的最终一致性策略，或保留多版本，一般不涉及类似 KV数据库 的复杂一致性保证。
文件存储 (Filesystem)
分布式文件存储，常简称为 DFS 或 NAS，核心是为用户提供 POSIX 语义，能够像本地文件系统一样挂载和使用。
适用场景
用户可能有成千上万个容器同时挂载同一个文件存储卷（Volume）。适用于 AI 训练、容器内日志持久化、文件共享与备份等场景。
特性：POSIX接口与文件树
分布式文件系统的语义兼容 POSIX。其元数据在用户视角呈现为文件-文件夹的树形结构，这意味着目录操作（如 stat, rm, mv 等）是原生且高效的。
图：CephFS 的元数据组织方式[6]，对用户呈现树形结构，内部采用动态子树分区策略
具体的 POSIX 语义兼容程度需参考具体系统的设计目标和官方文档。
特性：一致性、并发保护与性能的权衡
一个普遍规律是：性能与严格的 POSIX 原子性、一致性通常处于天平的两端。为了提升并发性能，系统可能会放松某些一致性保证。反之，一个提供严格 POSIX 原子性和一致性的文件系统，必然会引入更多的提交与补偿逻辑，从而影响性能。
常见的以一致性换取性能的手段包括：
- 不支持多客户端“并发写同一文件”，仅保证“单写者+多读者”的弱一致性。
- 追加写场景：牺牲“实时一致性”，保证“最终一致性”。
- 文件创建/删除场景：牺牲“跨客户端即时一致性”，保证“最终一致性”。
- 副本写入场景：牺牲“强原子性”，保证“最终副本一致性”。
块存储 (Block Storage)
块存储，顾名思义，直接为用户提供一个远程的块设备，可以像本地硬盘一样挂载和使用。
它与文件存储、对象存储的最大区别在于，块存储服务提供一个线性的存储空间布局。以下图为例，展示了 CurveBS 块设备的布局映射。
图：CurveBS 块设备的布局映射[1]
用户可以直接在其上格式化为 ext4 等本地文件系统。块设备服务本身不感知用户如何管理文件系统元数据，它只提供一个线性的块空间。
适用场景
块存储常被用作虚拟机（VM）的系统盘、数据库的数据盘，因此对延迟（微秒级）和稳定性（如 P999 延迟无抖动）要求极高。考虑数据库读写场景，一个同步 IO 被挂起，可能导致后续操作失败，就如同本地磁盘故障导致系统卡顿一样。
用户通常不追求单个块设备的极致容量，规模一般在 GiB 到 TiB 级别。
性能级别
以阿里云 ESSD 系列块存储的服务指标为例，可以对性能数量级有一个直观认识：
成本考量
值得指出的是，为了实现微秒级的性能，块存储几乎无可避免地需要使用 RDMA 和 NVMe 等技术。与毫秒级的对象存储和文件存储相比，这必然导致成本大幅提升。用户需要充分认识到块存储的特点，根据自身业务需求选择合适的产品。
实际上，许多数据分析、AI 训练项目采用了混合存储模式：块存储作为高性能缓存处理热点数据，对象存储存储海量冷数据。例如 Alluxio，它将多种底层存储编排为统一接口，成为一种高效的分布式存储中间件。
小结
| 存储形态 |
典型用户场景 |
核心优势 |
IO延迟 |
数据规模 |
| 对象存储 |
海量媒体、AI训练、备份归档 |
线性扩展性强、成本低、高并发、支持互联网访问 |
ms级 |
EiB级 |
| 文件存储 |
容器共享、AI训练、传统应用迁移 |
兼容POSIX、可直接挂载、支持文件树操作 |
us或ms级 |
TiB级 |
| 块存储 |
VM系统盘、数据库、高并发交易系统 |
微秒级延迟、高IOPS、高稳定性 |
us级 |
TiB级 |
分布式存储组件设计
了解了常见的产品形态后，我们再来探讨另一个必要的前置知识：分布式存储系统的常见组件设计。
核心三组件：元数据、存储引擎与客户端
元数据与存储引擎的分层设计，常见于对象存储和文件存储。一篇综述论文[2]描述了常见的分布式存储组件，如下图所示。
元数据组件
元数据存储文件/对象的属性信息及其在存储引擎上的物理映射。
大型分布式对象/文件集群需要管理千亿乃至万亿级别的元数据项。一个重要流派是将元数据管理独立出来，作为与存储引擎并行的组件，甚至直接采用 NoSQL数据库 来获得近线性的扩展能力。
块存储主要为用户提供线性块空间，元数据管理量级相对较小，通常采用单组高可用的共识节点即可管理。
存储引擎组件
存储引擎将众多存储节点和磁盘组织起来，对上提供统一的存储接口（如 PUT/DEL），对内负责数据管理、路由和冗余修复等工作。
这种分层易于理解，因为上层逻辑（元数据层）无需关心数据具体如何放置在磁盘上，也不需知道磁盘损坏后数据如何修复。
分层设计也有利于灵活部署。例如，对于 10 PiB 的数据，可能是万亿个小文件，也可能是百万个大文件。分层允许根据不同的数据规模，为元数据系统和存储引擎分别选择合适的硬件资源独立部署。
客户端组件
客户端的设计可轻可重，取决于系统架构。
以块存储为例，客户端必须提供挂载所需的驱动，计算布局映射，并处理后端少数磁盘故障的转移逻辑。而一个对象存储的客户端，可能只需要向指定的冗余组写入或读取对象，逻辑相对简单。
这三大组件共同构成了分布式存储系统最常见的模型。例如 CubeFS 的架构就是一个生动的示例：
图：CubeFS 的组件架构[7]
动手实践：创建你的分布式存储设计CheckList
云服务演化出的几种典型存储产品，并不意味着存储形态仅限于此。如果我们正在为特定场景设计一个专用的存储产品，必须提前明确目标需求。以下是一个初步的CheckList模板。
CheckList 模板
- 时延要求：毫秒级？微秒级？
- 文件大小：大文件？小文件？大小文件混合比例？
- 语义复杂性：完全兼容POSIX？还是简化的文件语义？
- 并发与竞争：高度竞争（反复覆盖同一文件）？高度分散（几乎无竞争）？
- 集群规模：TiB？PiB？EiB？百万文件？十亿文件？千亿文件？
- 性能需求：追求极致吞吐？还是便捷的线性扩缩容？
- 冗余要求：是否愿意以部分可靠性换取性能？
不同的需求必然对应不同的设计方案。存储研发人员必须对需求高度敏感，才能选择或创造出最合适的分布式存储系统。
下面，我们假想一个内部AI训练场景，尝试设计一个全新的分布式存储系统。我们将一起填写这份CheckList，并探讨可能采用的技术手段（注：部分需求为设想，仅用于演示设计思路）。
练习：CheckList与技术选型思路
与需求方（假想为“AI训练与推理团队”）深入讨论并确定需求。
| 评估维度 |
具体需求 |
适配的技术选型 / 优化思路 |
| 时延要求 |
越快越好，微秒级最佳 |
1. 硬件采用SSD与RDMA网络；<br>2. 引入用户态网络协议栈；<br>3. 软件层面深度优化内存拷贝等核心路径，关注CPU损耗与NUMA架构；<br>4. 尝试极致的RTC（Run-to-Completion）模型。 |
| 文件大小 |
上层已组织好，以大文件读写为主 |
元数据规模适中，可在客户端缓存全部元数据，减少查询开销。 |
| 语义复杂性 |
语义简单，无需复杂文件夹管理与严格原子性 |
倾向于采用KV结构存储元数据，易于管理和扩展，并可复用成熟的KV基础软件以降低开发成本。 |
| 并发与竞争 |
用户文件读写几乎无竞争 |
1. 通过合理的元数据分片策略分散访问压力；<br>2. 分布式事务仅作为补偿机制，因无竞争，对性能影响小。 |
| 集群规模 |
存储量达PiB级，文件总数十亿级 |
1. 优先扩展存储介质以匹配吞吐和容量；<br>2. 平均文件大小近1GiB，需重点优化存储节点的IO性能，避免其成为瓶颈。 |
| 性能需求 |
不考虑硬件成本，追求极致吞吐（GPU资源远比存储硬件昂贵） |
1. 内部网络传输速度至关重要；<br>2. 存储介质几乎必然选用高性能NVMe SSD，最大化IO吞吐。 |
| 冗余要求 |
可接受部分可靠性换取性能 |
采用两副本，在保证冗余的同时提升极限读取性能。 |
练习：系统最终选型与理由
基于上述CheckList，形成初步的系统设计选型。
| 模块 |
具体选型与理由 |
| 硬件 |
PCIe 5 NVMe 高性能机型 + RDMA 网络 |
| 软件基础设施 |
极致的RTC模型 + 用户态网络栈 + SPDK，RPC框架需支持RDMA |
| 元数据系统 |
直接选用外部NoSQL KV数据库，大幅节省研发成本 |
| 存储引擎系统 |
采用逻辑磁盘组成冗余组进行管理（便于管理和故障恢复），内部切分为MiB级别的块以适应大文件存储和高吞吐 |
| 控制面节点 |
PiB级别磁盘冗余组管理 + 路由 + 迁移任务，单组3节点高可用架构即可满足 |
| 客户端设计 |
支持元数据全缓存，以降低元数据访问成为瓶颈的可能性 |
关于技术选型思维的思考
上述选型结果，是否与某些开源项目（如3FS）有相似之处？这恰恰说明，构建自己的分布式存储系统，需要在掌握一定设计案例的基础上，紧密结合用户的具体需求，选择合适的技术手段。
这类系统没有放之四海而皆准的完美设计。试图满足所有需求，往往意味着需要在极致性能、运维便利性或其他方面做出妥协。熟练掌握这种技术选型的思维，或许正是一名分布式存储开发者走向成熟的标志。
总结
本节与前一节共同概述了对象存储、块存储、文件存储的适用场景与技术特点。随后，我们探讨了分布式存储的经典三组件：元数据系统、存储引擎和客户端。
我们设计了一份CheckList，并基于一个假想场景，共同完成了一套专属的分布式存储系统技术选型方案。
在后续的章节中，我们将针对CheckList中的各项技术选型展开深入讨论。至此，分布式存储的“科普”之旅暂告一段落，是时候向更深入的技术细节进发了。
1.CurveBS Client 架构介绍↩︎
2.H. Dai, Y. Wang, K. B. Kent, L. Zeng and C. Xu, "The State of the Art of Metadata Managements in Large-Scale Distributed File Systems — Scalability, Performance and Availability" in IEEE Transactions on Parallel and Distributed Systems, vol. 33, no. 12, pp. 3850-3869, 1 Dec. 2022, doi: 10.1109/TPDS.2022.3170574.↩︎
3.Cloudflare R2 - Pricing↩︎
4.阿里云 ESSD（Enterprise SSD）云盘↩︎
5.Alluxio/alluxio - GitHub↩︎
6.CephFS Dynamic Metadata Management↩︎
7.Liu, Haifeng, et al. "Cfs: A distributed file system for large scale container platforms." Proceedings of the 2019 International Conference on Management of Data. 2019.↩︎
发表于 昨天 02:49
|
查看: 0|
回复: 0
