4.6 动手做！你专属的分布式存储设计 CheckList

必须指出的是，云服务演化成为几种典型的存储产品，不代表存储形态只有这几种！

假设我们正在做正在做一个专精某个场景的存储产品，一定要提前约定好目标场景，比如以下的分项 checklist。

CheckList 模板

• 时延要求：毫秒？微妙？
• 文件大小：大文件？小文件？大小文件混合比例(1:10,3:7,5:5)？
• 语义复杂性：完全兼容 POSIX？简单的文件语义？
• 并发与竞争：高度竞争（重复覆盖写某一个文件）？高度分散（几乎无竞争）？
• 集群规模： TiB？PiB？EiB？百万文件？十亿文件？千亿文件？
• 性能需求：极致的吞吐？方便的线性扩缩容？
• 冗余要求：是否接受可靠性换性能？

不同需求必定对应不同的设计手法。存储研发人员必须对需求敏感，才能选用或创造出最适合用户的分布式存储系统。

下面，我们假想一个内部 AI 训练场景，去思考设计一个全新的分布式存储系统。

我们一起来填写这张 Checklist，并幻想我们可能使用的一些手段（注：部分需求为笔者臆想，一个初步的设计和选型思路练习，仅供演示分布式存储研发的设计思路）。

练习1：CheckList 和技术潜在选型

和需求方仔细讨论、调研，确定具体需求和共同的演化方向。

假想需求方：AI 训练和推理团队

评估维度	具体需求	适配的技术选型 / 优化思路 / 可能的演化方向
时延要求	越快越好，微秒级最佳	1. 硬件层面采用SSD搭配RDMA网络； 2. 网络协议层面引入用户态网络技术； 3. 软件层面高度优化内存复制等核心流程，重点关注 CPU 性能损耗与 NUMA 架构带来的性能损失； 4. 可尝试极致的 RTC 模型提升响应效率
文件大小	上层已完成数据组织，以大文件读写为主	元数据规模保持适中水平，也许可在 client 端实现元数据全缓存，减少元数据查询的网络开销
语义复杂性	语义逻辑简单，无复杂文件夹管理需求，无严格原子性要求	偏向于采用KV 结构存储元数据，既能满足基础语义需求，又具备易管理、易扩展的优势，同时可直接复用成熟的 KV 基础软件降低开发成本
并发与竞争	用户文件读写几乎无竞争场景	1. 通过合理的元数据 sharding策略分散访问压力，也许就满足并发需求； 2. 分布式事务仅作为补偿机制使用，因无竞争场景，不会对整体性能造成显著影响
集群规模	存储量级达 PiB 级，文件总数达十亿级	1. 优先扩充存储介质数量，适配大规模存储吞吐和容量； 2. 平均文件大小逼近 1GiB，需重点关注存储节点的 IO 性能，避免存储节点成为性能瓶颈
性能需求	不考虑硬件成本，追求极致吞吐（GPU 资源价值远高于存储硬件）	1. 内部互联网络的传输速度非常重要； 2. 存储介质几乎无疑采用极致性能的NVMe SSD，最大化存储 IO 吞吐能力
冗余要求	可接受部分可靠性换性能	采用两副本，保证冗余同时提高极限读性能

练习2：系统最终选型和理由阐述

以上述 CheckList 为基础，选取合适的技术栈/分布式技术手段设计系统选型。

模块	具体内容
硬件	PCIe 5 NVMe 高性能机型 + RDMA 网络
软件基础设施	极致的 RTC 模型 + 用户态网络栈 + SPDK 等技术，RPC 框架要支持 RDMA
元数据系统	直接使用外部 NoSQL KV 数据库，节省大量研发成本
存储引擎系统	采用逻辑磁盘结成冗余组管理（方便管理和故障恢复），内部切分 MiB 级别 block 以适应大文件存储和吞吐
控制面节点设计	PiB 级别磁盘冗余组管理 + 路由管理 + 千亿任务，单组 3 节点高可用绰绰有余
客户端设计	支持缓存元数据以减少元数据瓶颈可能性

刻意练习：技术选型的 sense

哈哈，上面这个选型结果，是不是很像前段时间开源的 3FS？笔者只是想表达，打造自己的分布式存储系统，就是要在掌握一些设计案例后，重点针对用户的需求，选择合适的手段。

这类系统没有普适的完美设计。要兼顾一切需求，往往意味着要牺牲极致性能或牺牲运维便利性等方面做出妥协。

而熟练掌握这个技术选型的 sense，也许就意味着开发者从分布式存储研发中登，逐渐成长为老登了罢。

小结

和上节一起，首先普适性地讲述了对象存储、块存储、文件存储适用的场景和技术特点。随后探索了分布式存储经典的三大组件：元数据系统、存储引擎和客户端。

我们设计了一个 CheckList，并一起思考打造了一个专属我们的分布式存储系统技术选型列表。

在后续章节，我们势必将针对 CheckList 中的各类技术选型展开细致讨论！别忘了，我们至此才刚刚结束了分布式存储的 “科普” 之旅。是时候摩拳擦掌，向真正的分布式存储中老登，进发！✋🏻😭✋🏻