很多刚刚进入存储行业或者想要转行到分布式存储行业的工程师，经常有困惑，就是“一名分布式存储工程师的技能树是怎样的？”
于是我们高举这个问题专门去找了我们的研发大拿们。
先说主题：“一名分布式存储工程师的技能树是怎样的？”我们认为广义上存储应该包含数据库，不过分布式数据库一般是“独挡一面”的：技术特点、技术难度、应用场景上都独具特色。
讨论分布式数据库完全可以是一个单独的话题，因此这里先聚焦讨论分布式数据库之外的分布式存储。
分布式存储的话题还是很大，从访问语义上，一般分为对象存储、块存储和文件存储。
先说对象存储，它的应用场景相对来说略窄，不如块存储是云计算的基石（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，客户一般都用的非常顺畅。转到分布式文件系统后，数据都是分布式放置，数据可能在本地，也可能在远端，性能还能满足客户的需求吗？如何保障？
分布式文件系统一般都会用各种缓存，比如利用到客户端缓存，那么如何保证各个客户端之间的缓存一致性？
我们认为分布式文件存储很有理论高度，也很有工程挑战。近年来国内技术进步非常快速，技术分享也很全面。分布式存储的关键理论，网上已经有很多，但需要新入行的朋友们去梳理脉络，从而自己去建立知识树。
互联网把世界拉平的同时，也把知识边界拉平了，你总能找到关于某个子话题的技术资料，但难就难在你需要知道有这个子话题，难在你需要知道要找哪方面的资料。
因此我们认为，对于资深的分布式存储工程师来说，挑战主要是优秀的工程实践，主要是如何去把模块实现得更简洁、更合理、更高性能。
而对于刚入行，想做分布式存储的工程师，或者具体一些，想做分布式文件存储的朋友们来说，需要有机会去体验构建分布式存储的实际过程，挑战主要是如何建立一棵正确的知识树 —— 这也是本话题的目标。
根据我们的经验，要自己单打独斗地去构建这样的知识树，耗时很长，且对个人综合能力要求很高。
因此我们是非常推荐各位参与一个分布式存储的项目。
可以是开源项目，也可以加入做分布式存储的公司。
