共计 1646 个字符，预计需要花费 5 分钟才能阅读完成。
很多刚刚进入存储行业或者想要转行到分布式存储行业的工程师，常常有困惑，就是“一名分布式存储工程师的技能树是怎么的？”
于是咱们高举这个问题专门去找了咱们的研发大拿们。
先说主题：“一名分布式存储工程师的技能树是怎么的？”咱们认为狭义上存储应该蕴含数据库，不过分布式数据库个别是“独挡一面”的：技术特点、技术难度、利用场景上都独具特色。
探讨分布式数据库齐全能够是一个独自的话题，因而这里先聚焦探讨分布式数据库之外的分布式存储。
分布式存储的话题还是很大，从拜访语义上，个别分为对象存储、块存储和文件存储。
先说对象存储，它的利用场景相对来说略窄，不如块存储是云计算的基石（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，客户个别都用的十分顺畅。转到分布式文件系统后，数据都是分布式搁置，数据可能在本地，也可能在远端，性能还能满足客户的需要吗？如何保障？
分布式文件系统个别都会用各种缓存，比方利用到客户端缓存，那么如何保障各个客户端之间的缓存一致性？
咱们认为分布式文件存储很有实践高度，也很有工程挑战。近年来国内技术提高十分疾速，技术分享也很全面。分布式存储的要害实践，网上曾经有很多，但须要新入行的敌人们去梳理脉络，从而本人去建设常识树。
互联网把世界拉平的同时，也把常识边界拉平了，你总能找到对于某个子话题的技术材料，但难就难在你须要晓得有这个子话题，难在你须要晓得要找哪方面的材料。
因而咱们认为，对于资深的分布式存储工程师来说，挑战次要是优良的工程实际，次要是如何去把模块实现得更简洁、更正当、更高性能。
而对于刚入行，想做分布式存储的工程师，或者具体一些，想做分布式文件存储的敌人们来说，须要有机会去体验构建分布式存储的理论过程，挑战次要是如何建设一棵正确的常识树 —— 这也是本话题的指标。
依据咱们的教训，要本人单打独斗地去构建这样的常识树，耗时很长，且对集体综合能力要求很高。
因而咱们是十分举荐各位参加一个分布式存储的我的项目。
能够是开源我的项目，也能够退出做分布式存储的公司。
