一名分布式存储工程师的技能树是怎样的？

很多刚刚进入存储行业或者想要转行到分布式存储行业的工程师，经常有困惑，就是“一名分布式存储工程师的技能树是怎样的？”

于是我们高举这个问题专门去找了我们的研发大拿们。

先说主题：“一名分布式存储工程师的技能树是怎样的？”我们认为广义上存储应该包含数据库，不过分布式数据库一般是“独挡一面”的：技术特点、技术难度、应用场景上都独具特色。

讨论分布式数据库完全可以是一个单独的话题，因此这里先聚焦讨论分布式数据库之外的分布式存储。

分布式存储的话题还是很大，从访问语义上，一般分为对象存储、块存储和文件存储。

先说对象存储，它的应用场景相对来说略窄，不如块存储是云计算的基石（IaaS时代，你创建个虚拟机，总得有块硬盘吧），它不如文件存储历史之久和应用之广，这主要是上层应用的访问语义决定的，上层应用大多要么通过虚拟化的块存储访问语义，要么通过文件POSIX语义访问数据。

技术实现上，AWS S3是对象存储的事实标准，对象不支持更改，能接受短期的副本间的数据不一致。

对象存储的特点是追求低成本，实现EC往往是必需的。

接下来，我们讨论分布式块存储和分布式文件存储。它们的共性一般是追求高性能，追求数据强一致性。分布式块存储一般是给虚拟机提供虚拟硬盘的，亦即各大公有云的EBS产品，大多数应用场景中，它只被一个客户端使用。而分布式文件系统往往被多个客户端并发使用，会面临并发的、海量的文件读写，技术上难度系数比较高。

我们的YRCloudFile定位是高性能分布式文件系统，因此我们把重心放在着重讨论分布式文件系统工程师的技能树。鉴于每个部分都可做单独议题展开，所以这里仅简述。

我们认为的分布式文件存储工程师的技能树主干：

1）介质：

基于HDD设计是一回事，基于高性能SSD设计就完全是另外一回事了。比如基于HDD用普通同步线程就够了，基于SSD，同步线程是跑不满硬件的，如果要进行IO polling的话，libaio好不好用，用内核最新的io_uring稳定性是否ok，都是面向SSD设计分布式文件存储时要使用的技能。另一方面，设备的低延时也突出线程上下文切换的性能损耗。

2）元数据架构：

是做有元数据结构，还是做无元数据的分布式结构。

我们通过对比和选型，选择了有元的。那么目录树如何切分？集群成员关系如何建立和维护，各种异常网络情况下，关于某个节点是死是活，集群各个成员能否达成一致？这也都是分布式文件存储工程师技能树上要掌握的内容。

3）可靠性和一致性：

防止某块盘彻底坏了，要容错，一般都做副本，要么是多副本，要么用EC。那如何保证副本间数据的一致性？

4）效率：

很多客户都习惯于使用Linux本地文件系统，因为有pagecache，因此即便硬盘是HDD，客户一般都用的非常顺畅。转到分布式文件系统后，数据都是分布式放置，数据可能在本地，也可能在远端，性能还能满足客户的需求吗？如何保障？

分布式文件系统一般都会用各种缓存，比如利用到客户端缓存，那么如何保证各个客户端之间的缓存一致性？

我们认为分布式文件存储很有理论高度，也很有工程挑战。近年来国内技术进步非常快速，技术分享也很全面。分布式存储的关键理论，网上已经有很多，但需要新入行的朋友们去梳理脉络，从而自己去建立知识树。

互联网把世界拉平的同时，也把知识边界拉平了，你总能找到关于某个子话题的技术资料，但难就难在你需要知道有这个子话题，难在你需要知道要找哪方面的资料。

因此我们认为，对于资深的分布式存储工程师来说，挑战主要是优秀的工程实践，主要是如何去把模块实现得更简洁、更合理、更高性能。

而对于刚入行，想做分布式存储的工程师，或者具体一些，想做分布式文件存储的朋友们来说，需要有机会去体验构建分布式存储的实际过程，挑战主要是如何建立一棵正确的知识树 —— 这也是本话题的目标。

根据我们的经验，要自己单打独斗地去构建这样的知识树，耗时很长，且对个人综合能力要求很高。

因此我们是非常推荐各位参与一个分布式存储的项目。

可以是开源项目，也可以加入做分布式存储的公司。

重点来了：

我们非常欢迎各位高手、新手的加入。如果你是新手，成功加入我司，我们相信你一定会在更短时间内理解分布式文件存储理论的方方面面，以及工程实践的方方面面，会有足够的技术挑战，让你在更短时间内去建立前面提及的属于你个人的知识树。