共计 4036 个字符，预计需要花费 11 分钟才能阅读完成。
前言
文件系统是最罕用的数据存储模式，所以，罕用 Linux 操作系统的用户必然晓得 ext4、xfs 等单机文件系统，用 Windows 操作系统的用户也都晓得 NTFS 单机文件系统。各种业务场景下，不同的数据都存储于文件系统之上，大量业务逻辑就是基于文件系统而设计和开发的。提供最罕用的存储拜访形式，这是咱们做文件系统的出发点之一。
另一方面，单机文件系统有其显著限度，次要是容量、文件数量限度，以及牢靠、可用性限度。单机文件系统毕竟存储空间无限，且掉电或坏盘等故障会带来数据不可达或失落。通过分布式文件系统解决这些问题，这是咱们的出发点之二。
但做分布式文件系统会面临很多挑战，也会面临十分多的抉择。
Google GFS 论文面世之后，Hadoop HDFS 随之诞生，HDFS 的抉择是解决大文件，面向 MapReduce 这种非在线数据分析业务，重吞吐而非延时，对 HDFS 外部存储的数据进行拜访，须要借助其提供的专有命令行和 SDK，意味着它并不是一个通用型的文件系统。它的次要架构是元数据服务（本文对立用 MetaData Service 的缩写 MDS 来指代元数据服务）和数据服务（本文对立用 Data Storage Service 的缩写 DSS 来指代数据服务），其中 MDS 是单点的，单点的 MDS 能做出统一的决策，为了保障 MDS 可靠性，个别会抉择再做一个备份。HDFS 的 DSS 则能够是很多个。因为文件大小和模式固定，元数据量不会太大，因此实践上单点 MDS 就能够撑持，不过单 MDS 仍限度了集群的规模。
HDFS 之后，呈现了一些其余的开源分布式文件系统，比方 MooseFS。它也是相似的 MDS+OSS 架构，区别于 HDFS 的是，MooseFS 没有对运行其上的业务做假如，它没有假如业务是大文件或海量小文件，也就是说，MooseFS 的定位是像 ext4、xfs、NTFS 等单机文件系统一样的通用型文件存储。其实 MooseFS 底下用的就是单机文件系统，能够认为它只是将多台机器上的多个单机文件系统做了一个“逻辑上”的聚合，之所以这么说，是因为从数据角度，它次要是实现了一个多正本性能，而正本间的数据一致性并没有去庄重地保障。从元数据角度，MooseFS 提供了一个实质上就是单机的 MDS，但为了保障元数据的可靠性，MooseFS 通过某些机制，靠近实时地备份了元数据。
另外一个更为出名的开源分布式文件系统就是 GlusterFS 了，相比 MooseFS 等文件系统，GlusterFS 的显著特点是它的“无元”架构，即它没有独立的 MDS，GlusterFS 应用一致性哈希算法去定位元数据和数据。咱们在设计和开发本人的文件系统时，并没有抉择这样的架构，因为它的毛病非常明显，例如元数据操作性能很差，而文件系统日常应用中，对元数据的操作占日常操作的比例比极高 (50% 以上)；此外，这种“无元”的文件系统架构对故障的应答不够灵便，服务器进入集群或退出集群都会引起一致性哈希算法的从新计算，从而带来局部数据的迁徙，进而影响业务 IO。
近两年来，CephFS 成为开源分布式文件系统的一颗璀璨新星。Ceph 的 RADOS 对象存储层是一个实践齐备且实现优良的零碎。CephFS 基于 RADOS，它的元数据和数据都是存储到 Ceph RADOS 之中。Ceph 的哲学是首要确保数据稳定性而轻性能，但事实利用中性能往往也是强需要之一，某些场景甚至要求更看重性能。CephFS 架构上利用了 RADOS，它的 MDS 数据也存储到 RADOS 上，而不是存储到本地硬盘，实践和实现角度上看，这种做法能够复用 RADOS，但也带来了较大的性能衰减。
CephFS MDS 是反对 Active-Active 模式的，MDS 不再是单点，多个 MDS 独特保护一个对立的命名空间。CephFS 实现了它本人提出的动静子树划分算法，其指标是依据文件系统热点状况对 MDS 做动静的压力平衡。不过在大规模生产环境中，这个性能会带来运维的复杂度，因此理论被开启的不多。
人工智能、挪动互联时代的一大数据特色，就是海量文件，为了做一个反对百亿级文件的分布式文件系统，咱们该如何思考和设计呢？
方法论
在确定“方法论”之前，咱们要先建设一些原则性意识。
其一是不会有 one size fits all，咱们不可能兼顾所有，必须有侧重点，有偏重就会有舍弃。“取舍”，置信是大多分布式开发者的心得。比方分布式系统，咱们不可能冲破 CAP 实践限度。面对各种各样的业务需要，如果咱们只满足 CP，有的业务对 A 有强需要怎么办？如果咱们只满足 AP，那置信咱们强调数据一致性的存储工程师就不违心入手，因为咱们深知数据稳固是要坚守的底线。因而咱们会细化，会反对针对业务的 CA 能够进行肯定水平上的配置。
其二是要围绕“主线”去做设计，否则下层的实现会积重难返。咱们的外围主线之一就是反对百亿千亿级别文件海量文件。从这个主线登程，咱们会去针对性地思考关键问题，去做要点设计。咱们都晓得，外围设计决定将来。后面探讨到的 MooseFS 和 GlusterFS 等，为咱们泛滥分布式系统研发者提供了学习案例，在它们根底上实现不了百亿级文件，因为曾经积重难返。
上面从这两个准则登程，来讨论一下咱们设计本人的分布式文件系统时思考的要点。
要点设计
要反对百亿级文件，从后面“方法论”提出的大思路登程，咱们认为要实现的关键点有以下几点。
采纳核心元数据服务器（即 MDS）
这简直是必然选择，只有应用了 MDS，CAP 中的 A 才更为可控，零碎的整体架构也更加清晰，故障解决更加自若，数据搁置策略、故障复原策略也将更加不便和可控，因为这些行为都在 MDS 管制之下。
咱们应用多 MDS 独特组成一个对立的命名空间，为了反对百亿级，对目录树必须做切分。围绕“切分”思路，咱们能够做多种切分策略，不同策略有不同的成果。如何做策略就是工程实际问题了，从我的项目管控以及工程实现的复杂度角度思考，咱们目前实现的策略是按目录哈希切分策略，这曾经能满足大多数场景的需要。在将来，咱们会再实现其余策略。
MDS 的另一设计要点是，是否应用本地硬盘。产生这点思考，是借鉴到了 CephFS 的教训，CephFS 复用 RADOS，有益处也有害处，害处是性能受到较大影响，益处是工程实际角度更为清晰。咱们认为，对元数据的操作要更器重性能，因而咱们动摇地抉择了 MDS 间接对接本地硬盘。
抉择 MDS 应用本地硬盘后，下一个要思考的要点是，是否间接应用本地 MDS 节点的文件系统，如 ext4 或 xfs。应用本地文件系统，开发和实现会更加高效，，目前咱们的抉择是间接应用 MDS 的本地文件系统，未来，为了进一步晋升 MDS 的操作性能，咱们会间接操作裸盘的 KV 零碎。
数据存储（即 DSS）要点
DSS 次要思路是 bypass 文件系统，跟 MDS bypass 文件系统相似，这里有两个阶段的考量，第一阶段利用本地文件系统，能疾速实现性能。第二阶段是 bypass 文件系统，DSS 间接操作裸盘，即做出一个独立的单机存储引擎，咱们的次要思考点是单机文件系统不利于海量小文件的存储和治理；其次，单机裸盘存储引擎，有助于咱们谋求更极致的性能，裸盘引擎更利于未来咱们对 NVMe 等新型硬件和 SPDK 等新型技术栈做深刻整合。目前，咱们曾经推出了基于裸盘的 DSS 存储引擎。
集群治理要点
分布式集群中，如何对节点是否离线、是否退出等要害事件进行断定，也是要思考的外围问题之一。咱们将这些工作交给集群治理节点，或称为 monitor 来解决。如何实现 monitor 集群，不须要多多思考，基本上是实现一个 paxos 集群，近几年来用 raft 是一个“风行”趋势。
正本机制和 CAP 开关
正本机制是分布式系统实现数据可靠性的要害思路，它带来的 CA 问题将是面对不同业务时须要思考的均衡点。如“方法论”所述，咱们将 CA 的衡量做成选项，在不同利用场景中能够有不同的偏重。在这个简略思路之上，魔鬼就在简单的细节里，难点次要在工程实际之中，短缺的测试是验证这一机制的办法。
“瑞士军刀”式性能开关
要实现百亿级分布式文件存储，以上探讨了咱们的出发点和“方法论”的要害要点。基于这些点做进去的零碎是“骨架”残缺的。
但仍如“方法论”所说，没有 one size fits all 的零碎，咱们接触的客户需要都是各种各样的，不会一个零碎能满足所有业务场景和需要。因此咱们的思路是在下面的外围之上，去做丰盛的性能，并将次要性能做成开关式管制，某些甚至反对运行时调整。
上面探讨一些次要的性能
分池存储
一个较大规模的分布式集群中，往往会引入不同类型的存储设备。另一方面，用户的多种业务中，往往有要害业务和非关键业务之分。这两个角度，不论从哪个角度来思考，咱们都发现，有将物理资源分池治理的必要性。因而咱们实现了对物理资源分池治理的性能，也可称之为分组、分 zone，叫法无所谓，其外围要义是提供物理资源划分的能力。
咱们实现了这个机制，目前基于这个机制，咱们实现了故障域划分的成果，将资源分配到不同池，实现物理上的故障域划分，减小故障时的影响。
分层存储
有不少业务会存储大量冷数据，对冷数据，往往谋求存储老本的节约。如果用户提供了 SSD 和 HDD，并打算将海量的 HDD 空间用作冷存储，用大量的 SSD 空间用作热存储。咱们能够将 HDD 空间分成一个池，将 SSD 空间分成一个池，逻辑上将 SSD 池架设到 HDD 池之上，实现一个分层存储的性能，将 SSD 池的冷数据转移到 HDD 池中去。
数据压缩
这个性能需要往往随同分层存储存在，针对冷数据存储，用户业务往往会再应用咱们的数据压缩性能先做数据压缩。
后记
本文“囫囵吞枣”般介绍了咱们是如何去思考和设计百亿级分布式文件系统的。以后网络资源丰盛，开源发达，通过借鉴其余零碎的教训，再加上以前的积攒，咱们对做一个百亿级分布式文件系统造成了本人的了解。简略来说做百亿级分布式文件系统，首先是一个思路问题，其次是也很有挑战的工程实际。本文次要简略地探讨了整体“思路问题”局部，当前有机会咱们再一起来探讨小模块的设计细节和实现问题。
