分布式存储GFS、TFS、HDFS、MooseFs、FastDfs、MogileFs、GridFs、MinIO、SeaweedFS、GlusterFS、Ceph、GlusterFS等
概述
本文基于经典的分布式文件系统，从架构和演化两个维度去分析，梳理其中的关键技术和未来的发展方向。
单方面追求某一个特定指标的最大化在实际的产品设计中并不可取，同时追求多个指标的最大化也是一件费力不讨好的事情，本质上违背了事务发展的客观规律。
作为一个系统，永远是追求多个维度，多个指标的平衡，Google GFS存在诸多的问题，但是不妨碍它成为Google存储的核心基础设施，HDFS的诸多问题也不妨碍它在Hadoop生态中地位。
同时我们也应该面向未来来看待问题，随着新的思想，新的硬件，新的场景的出现，通用的解决方案，放之四海而皆准的产品是不存在。
数据存储方式
文件、块和对象是三种以不同的方式来保存、整理和呈现数据的存储格式。这些格式各有各的功能和限制。
文件存储：会以文件和文件夹的层次结构来整理和呈现数据。
块存储：会将数据拆分到任意划分且大小相同的卷中。
对象存储：会管理数据并将其链接至关联的元数据。
三者的本质差别是使用数据的“用户”不同：
文件存储的用户是自然人
块存储的用户是可以读写块设备的软件系统，例如传统的文件系统、数据库
对象存储的用户则是其它计算机软件
块存储
块存储一般体现形式是卷或者硬盘（比如windows的c盘），数据是按字节来访问的，对于块存储而言，对里面存的数据内容和格式是完全一无所知的。块存储只负责数据读取和写入，因此性能很高，适用于对响应时间要求高的系统。比如数据库等。
文件存储
文件存储一般体现形式是目录和文件（比如C:\Users\Downloads\text.doc），数据以文件的方式存储和访问，按照目录结构进行组织。文件存储可以对数据进行一定的高级管理，比如在文件层面进行访问权限控制等。文件存储可以很方便的共享，因此用途非常广泛。比如常用的NFS、CIFS、ftp等都是基于文件存储的。
对象存储
对象存储一般体现形式是一个UUID，数据和元数据打包在一起作为一个整体对象存在一个超大池子里。对于对象访问，只需要报出它的UUID，就能立即找到它，但访问的时候对象是作为一个整体访问的。从设计之初衷（一般的对象存储都是基于哈希环之类的技术来实现），对象存储就可以非常简单的扩展到超大规模，因此非常适合数据量大、增速又很快的视频、图像等。
什么是分布式存储
在开始介绍分布式存储之前，先了解一下，非分布式的存储方案。
在单机时代，将文件直接存储在服务部署的服务器上——
直连存储（DAS）：存储和数据直连，拓展性、灵活性差。
为了扩展，将文件和服务分离，通过网络连接——
中心化存储（NAS、SAN）：设备类型丰富，通过网络互连，具有一定的拓展性，但是受到控制器能力限制，拓展能力有限。同时，设备到了生命周期要进行更换，数据迁移需要耗费大量的时间和精力。
分布式存储：通过网络使用企业中的每台机器上的磁盘空间，并将这些分散的存储资源构成一个虚拟的存储设备，数据分散的存储在企业的各个角落。
选型参考
适合做通用文件系统的有：Ceph、MooseFS、MinIO；
适合做中小文件存储的文件系统有：Ceph、FastDFS、MinIO、SeaweedFS；
适合做大文件存储的文件系统有：HDFS、MinIO、Ceph、GridFS；
轻量级文件系统有：FastDFS、MinIO、SeaweedFS；
简单易用，用户活跃的文件系统有：HDFS、FastDFS、MinIO；
综上：Ceph目前不够成熟稳定，官方也明确指出不要把ceph用在生产环境中，暂不考虑；
经初步筛选剩下的文件系统有：HDFS、FastDFS、MinIO、GridFS。
MinIO：学习成本低，部署容易，适合存储大容量非结构化的数据，且有详细的中文文档。
FastDFS：功能精简，支持在线扩容、冗余备份，部分支持跨集群同步，不存在单点故障，性能较好。但是不支持FUSE挂载和POSIX访问接口，且学习成本相对MinIO较高，且部署也相对比较复杂点。
HDFS：适合批量数据处理.可以部署在廉价的机器上。可以部署在廉价的机器上，但是不适合大量小文件，通过牺牲响应延时来换取高的吞吐量。
GridFS：能够简化技术栈,如果已经使用了MongoDB,那么使用GridFS，就不需要其它独立的存储工具了(但是我们当前没引入MongoDB)，不过性能不如直接访问文件系统快，而且无法修改文档。如果要修改GridFS里面的文档，只能是先删除再添加(对我们当前业务没有影响)
目前提供的建议选型参考为MinIO或FastDFS，
如果想减少技术栈的话可以考虑HDFS或GridFS，
如果不在乎响应时间可以考虑HDFS。
架构分析
纵观以上经典的分布式文件系统，从架构上看基本上可以划分为两大类：中心化架构和无中心化架构。两者区别就是如何存储元数据。
中心化架构
有专门的元数据存储服务，GFS就是典型的代表，这种架构的优势主要体现在系统整体结构清晰简单，集群调度灵活，缺点就是存在单点瓶颈。不过后来的架构演进的时候，对元数据的管理出现了两个方向：
对元数据存储进行分组，存在N组元数据服务，每一组独立负责一部分元数据。
将元数据存储在分布式KV系统中。比如Google第二代文件系统Colossus。
通常元数据都是存储在内存中，主要的目的是为了访问速度，但是也带来了新问题就是元数据高可用，需要有备份。HDFS被人诟病的一点就是它的元数据存储的高可用性。
无中心化架构
以GlusterFS为例，相比 MooseFS ，HDFS等文件系统，GlusterFS 的明显特点是它的“无元”架构，即它没有独立的元数据服务，GlusterFS 使用一致性哈希算法去定位元数据和数据。这种架构缺点非常明显，例如元数据操作性能很差，而文件系统日常使用中，对元数据的操作占日常操作的比例比极高(50%以上)；此外，这种“无元”的文件系统架构对故障的应对不够灵活，服务器进入集群或退出集群都会引起一致性哈希算法的重新计算，从而带来部分数据的迁移，进而影响业务 IO。
元数据管理技术
元数据的存取性能是整个分布式文件系统性能的关键。常见的元数据管理可以分为集中式和分布式元数据管理架构。集中式元数据管理架构采用单一的元数据服务器，实现简单，但是存在单点故障等问题。分布式元数据管理架构则将元数据分散在多个结点上，进而解决了元数据服务器的性能瓶颈等问题，并提高了元数据管理架构的可扩展性，但实现起来对相应产品的技术要求要高很多。
另外还有一种无专用元数据服务器的分布式架构，通过在线算法组织数据，不需要专用的元数据服务器。但是该架构对数据一致性的保障很困难，实现较为复杂，文件目录遍历操作效率低下，并且缺乏文件系统全局监控管理功能。
分布式元数据管理架构应该是解决超大规模存储的关键选择，Google的Colossus就是采用这种方式， AWS的分布式块存储也是类似的架构，采用蜂窝元数据架构，具备极致的容错性，可用性和扩展性。
文件系统未来展望
(1) 超高Scale-Out扩展能力：单一EB级存储系统，支持万级集群规模，可全球范围内全局部署；
(2) CompuStor超融合：类似Nutanix架构，计算、存储，甚至应用高度融合；
(3) 闪存技术应用：从主存、Cache到Tier分层，闪存无处不在；
(4) 高速网络互连：四/十万兆以太网和Infiniband网络得到普及；
(5) 应用感知：I/O更加智能，性能和效率动态自适应和优化；
(6) 纠错码技术：基于纠错码提供可用性，复制技术作为辅助；
(7) Online消重/压缩：成为系统标准配置，提高存储效率；
(8) 统一存储：池化存储，同时支持对象、块和文件存储。
根据需求选择分布式文件系统
目前可用于文件存储的网络服务选择有很多，比如阿里云OSS、腾讯云、百度云等等，对于中小型企业，如果不选择存储上云，或者为了帮节约成本，可自行部署文件系统。
对分布式文件系统的要求
对一个分布式文件系统而言，有一些特性是必须要满足的，否则就无法有竞争力。主要如下：
应该符合 POSIX 的文件接口标准，使该系统易于使用，同时对于用户的遗留系统也无需改造；
对用户透明，能够像使用本地文件系统那样直接使用；
持久化，保证数据不会丢失；
具有伸缩性，当数据压力逐渐增长时能顺利扩容；
具有可靠的安全机制，保证数据安全；
数据一致性，只要文件内容不发生变化，什么时候去读，得到的内容应该都是一样的。
除此之外，还有些特性是分布式加分项，具体如下：
支持的空间越大越好；
支持的并发访问请求越多越好；
性能越快越好；
硬件资源的利用率越高越合理，就越好。
架构组件
从业务模型和逻辑架构上，分布式文件系统需要这几类组件：
存储组件：负责存储文件数据，它要保证文件的持久化、副本间数据一致、数据块的分配 / 合并等等；
管理组件：负责 meta 信息，即文件数据的元信息，包括文件存放在哪台服务器上、文件大小、权限等，除此之外，还要负责对存储组件的管理，包括存储组件所在的服务器是否正常存活、是否需要数据迁移等；
接口组件：提供接口服务给应用使用，形态包括 SDK(Java/C/C++ 等)、CLI 命令行终端、以及支持 FUSE 挂载机制。
而在部署架构上，有着“中心化”和“无中心化”两种路线分歧，即是否把“管理组件”作为分布式文件系统的中心管理节点。两种路线都有很优秀的产品，下面分别介绍它们的区别。
主流架构
客户端
分布式文件系统客户端，是指针对分布式文件系统，需要有配套的接入端来实现用户能访问分布式文件系统，目前主流做法是两个，一个是原生客户端（Native client），另一个是协议网关代理服务。
原生客户端，设计配套的客户端接入（类似自定义一套私有的接入协议），如图2-1。分布式文件系统，需要提高可靠性和容错能力，设计基本采用集群方案，不是传统的C/S模型，而是多客户端对多服务端（Multi-C/Multi-S， 简称MC/MS）模型，类似DNS负载均衡。该模型需要在用户客户端能实现负载均衡，寻址定位等功能，因此必须使用与存储集群相配套的原生客户端（Native client）接入才能满足分布式系统设计要求。
协议网关代理服务，目的是为了兼容传统的网络文件系统协议（如NFS/FTP/CIFS），如图2-2；分布式文件系统基本都需要兼容传统网络文件系统协议，但传统网络文件系统协议（CIFS/NFS）针对的是点对点的C/S架构设计的协议，无法像分布式文件系统客户端那样，实现高性能高可靠的接入（pNF会引入并行访问能力，类似分布式文件系统架构，但不同分布式文件系统项目的后端架构都不相同，还无法做到直接对接该功能）。因此都需要采用网关代理模式，在代理服务器里集成分布式文件系统的原生客户端，间接访问存储集群。
主流产品分析
常见分布式文件系统比对
GFS（Google File System）
Google公司为满足公司需求而开发的基于Linux的可扩展的分布式文件系统，用于大型的、分布式的、对大数据进行访问和应用，成本低，应用于廉价的普通硬件上，但不开源，暂不考虑。
GFS系统包括master、多个chunkserver以及多个client。文件被切分为固定大小的小文件（chunk）。每个chunk创建时，master会分配一个64bit的全局唯一且不可修改的chunk handler来标志这个chunk。chunkserver负责将chunk存储在本地磁盘的Linux文件中，并通过chunk hander和byte range来读写chunk文件。为了提高可靠性，每个chunk都是多副本存储在多个chunkserver上，默认情况下是三副本。用户可以为不同名字空间下的文件配置不同的副本数。
GFS是典型的中心化架构设计，后来的很多分布式系统都参考这种架构。
优点
架构简单
集群水平扩展
可以构建在廉价的服务器上
存储容量大，支持PB级存储规模
缺点
适合大文件读写，不适合小文件存储
写文件支持Append模式
没有实现 POSIX 的标准文件接口
一致性不足（松弛一致性）
TFS（Taobao File System）
阿里巴巴为满足了淘宝对小文件存储的需求而开发的一个可扩展、高可用、高性能、面向互联网服务、开源的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，这个也暂不考虑。
TFS 和 FastDFS 应该更像是对象存储，没有提供 POSIX 兼容。
优点
适合小文件存储
弹性扩容
缺点
没有通用的文件访问接口，需要通过TFSClient进行接口访问
整体架构类似GFS，存在单点风险
HDFS（Hadoop Distributed File System）
Hadoop分布式文件系统，适合运行在通用硬件上做分布式存储和计算，因为它具有高容错性和可扩展性的特点，可部署在廉价的机器上，适合大数据的处理，在离线批量处理大数据上有先天的优势。
HDFS（Hadoop Distributed File System）是 Hadoop 项目的一个子项目。是 Hadoop 的核心组件之一， Hadoop 非常适于存储大型数据 (比如 TB 和 PB)，其就是使用 HDFS 作为存储系统. HDFS 使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统。
HDFS 一直是大数据领域专属，发展15年多了，只有 Java SDK 成熟，用它来做通用的业务开发肯定不方便。
优势
容错性：数据自动保存多个副本。通过增加副本的形式，提高容错性。其中一个副本丢失以后，可以自动恢复。
可以处理大数据：能够处理数据规模达到GB、TB甚至PB级别的数据；能够处理百万规模以上的文件数量。
可以构建在廉价的机器上，通过多副本机制，提高可靠性。
缺点
不适合低延时数据访问：比如毫秒级的存储数据，是做不到的。
无法高效对大量小文件进行存储：存储大量小文件的话，它会占用 NameNode 大量的内存来存储文件目录和块信息。这样是不可取的，因为 NameNode的内存总是有限的。同时，小文件存储的寻址时间会超过读取时间，它违反了HDFS的设计目标。
不支持并发写入、文件随机修改：一个文件只能有一个写，不允许多个线程同时写。仅支持数据 append（追加），不支持文件的随机修改。
MooseFS
MooseFS 是来自波兰的开源且具备冗余容错功能的分布式 POSIX 文件系统，也是参照了 GFS 的架构，实现了绝大部分 POSIX 语义和 API，它支持通过FUSE方式将文件挂载操作，同时其提供的web管理界面非常方便查看当前的文件存储状态，对master服务器有单点依赖，用perl编写，用于中、大型文件应用，但性能相对较差，由于可能会实时访问所以暂不考虑。
备注：POSIX表示可移植操作系统接口(Portable Operating System Interface of UNIX,缩写为 POSIX )，POSIX标准定义了操作系统应该为应用程序提供的接口标准
MooseFS 是欧洲项目，最近 10 年发展不多。
优势
由于MFS是基于GPL发布的，因此完全免费，并且开发和社区都很活跃，资料也非常丰富
轻量、易部署、易配置、易维护
通用文件系统，不需要修改上层应用就可以使用
扩容成本低、支持在线扩容，不影响业务，体系架构可伸缩性极强
体系架构高可用，所有组件无单点故障
文件对象高可用，可设置任意的文件冗余程度（提供比 Raid 10 更高的冗余级别）
提供系统负载均衡，将数据读写分配到所有的服务器上，加速读写性能
提供诸多高级特性，比如类似Windows的回收站功能、类似JAVA语言的GC（垃圾回收）、快照功能等
MooseFS 是 Google Filesystem 的一个 C 实现
自带 Web Gui 的监控接口
提高随机读或写效率和海量小文件的读写效率
缺点
Master Server本身的性能瓶颈。MFS的主备架构情况类似于MySQL的主从复制，从可以扩展，主却不容易扩展。短期的对策就是按照业务来做切分。
随着MFS体系架构中存储文件的总数上升，Master Server对内存的需求量会不断增大（MFS把文件系统的结构缓存到 Maset Server 的内存中）。根据官方提供的数据，8g对应2500万的文件数，2亿文件就得64GB内存。短期的对策也是按照业务来做切分。
Master Server的单点解决方案的健壮性。目前官方自带的是把数据信息从Master Server同步到Metalogger Server上，Master Server一旦出问题Metalogger Server可以恢复升级为Master Server，但是需要恢复时间。目前，也可以通过第三方的高可用方案（heartbeat+drbd+moosefs）来解决Master Server的单点问题。
Metalogger Server复制元数据的间隔时间较长（可调整）。
FastDFS
由淘宝的余庆先生所开发的一个开源分布式文件系统。它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。适合以文件为载体的在线服务，如相册网站、视频网站等等。FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS搭建一套高性能的文件服务器集群提供文件上传、下载等服务。但是FastDFS部署有点麻烦，且它的SKD是不全的。
FastDFS是一个开源的轻量级分布式文件系统。它解决了大数据量存储和负载均衡等问题。特别适合以中小文件（建议范围：4KB < file_size <500MB）为载体的在线服务，如相册网站、视频网站等等。在UC基于FastDFS开发向用户提供了：网盘，社区，广告和应用下载等业务的存储服务。
FastDFS是一款开源的轻量级分布式文件系统纯C实现，支持Linux、FreeBSD等UNIX系统类google FS，不是通用的文件系统，只能通过专有API访问，目前提供了C、Java和PHP API为互联网应用量身定做，解决大容量文件存储问题，追求高性能和高扩展性FastDFS可以看做是基于文件的key value pair存储系统，称作分布式文件存储服务更为合适。
FastDFS架构包括 Tracker server和Storage server。
Tracker server - 负载均衡和调度
通过Tracker server在文件上传时可以根据一些策略找到Storage server提供文件上传服务。可以将tracker称为追踪服务器或调度服务器。
Tracker角色：管理集群
tracker也可以实现集群。每个tracker节点地位平等。收集Storage集群的状态。
Storage server- 文件存储
客户端上传的文件最终存储在Storage服务器上，Storage server没有实现自己的文件系统而是利用操作系统 的文件系统来管理文件。可以将storage称为存储服务器。
Storage角色：实际保存文件
Storage分为多个组，每个组之间保存的文件是不同的。每个组内部可以有多个成员，组成员内部保存的内容是一样的，组成员的地位是一致的，没有主从的概念。
优势
1、主备Tracker服务，增强系统的可用性
2、系统不需要支持POSIX，这样的话就降低了系统的复杂度，使得处理的速度会更高
3、支持主从文件，支持自定义扩展名
4、支持在线扩容机制，增强了系统的可扩展性
5、实现了软RAID，增强了系统的并发处理能力和数据容错恢复能力
缺点
1、不支持断点续传，对大文件将是噩梦
2、同步机制不支持文件正确性校验，降低了系统的可用性
3、不支持POSIX通用接口访问，通用性比较的低
GridFS
MongoDB是一种知名的NoSql数据库，GridFS是MongoDB的一个内置功能，它用于存储和恢复那些超过16M（BSON文件限制）的文件(如：图片、音频、视频等)，是文件存储的一种方式，但是它是存储在MonoDB的集合中。它可以直接利用已建立的复制或分片机制，所以对于文件存储来说故障恢复和扩展都容易，且GridFS不产生磁盘碎片。
GridFS的基本原理是将文件保存在两个Collection中，一个保存文件索引，一个保存文件内容，文件内容按一定大小分成若干块，每一块存在一个Document中，这种方法不仅提供了文件存储，还提供了对文件相关的一些附加属性（比如MD5值，文件名等等）的存储。文件在GridFS中会按4MB为单位进行分块存储。
优点
能够简化技术栈,如果已经使用了MongoDB,那么使用GridFS,就不需要其它独立的存储工具了
GridFS会自动平衡已有的复制,或者为MongoDB设置的自动分片,所以对文件存储做故障转移或者是横向扩展会更容易 。
GridFS的功能不错,能自动解决一些其他文件系统遇到的问题,如在同一个目录下存储大量的文件
缺点
性能较低，不如直接访问文件系统快。
无法修改文档。如果要修改GridFS里面的文档，只能是先删除再添加
MinIO
MinIO 是一个基于Apache License v2.0开源协议的对象存储服务。它兼容亚马逊S3云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几kb到最大5T不等。它也是一个非常轻量的服务,可以很简单的和其他应用的结合。MinIO的特色在于简单、轻量级，对开发者友好，学习成本低，安装运维简单，开箱即用。
MinIO 是兼容 S3 API 的对象存储，没有 POSIX 兼容。优点是部署特别简单，缺点是不能动态增加节点，必须部署时确定集群规模，小对象性能不好，因为数据落盘是每个对象对应一个文件，直接存在本地文件系统上。
Minio采用去中心化的无共享架构，对象数据被打散存放在不同节点的多块硬盘，对外提供统一命名空间访问，并通过负载均衡或者DNS轮询在各个服务器之间实现负载均衡。
优点
学习成本低，安装运维简单，开箱即用
社区活跃
缺点
社区不够成熟，业界参考资料较少
不支持动态扩容。
minio创始人的设计理念就是动态增加节点太复杂，后续会采用其它方案来支持扩容。
minIO团队就是GlusterFS原班人马，他们的设计理念很类似。
SeaweedFS
SeaweedFS是基于go语言开发高度可扩展开源的分布式存储系统，能存储数十亿文件（最终受制于你的硬盘大小）、并且速度快，内存占用小。上手使用比fastDFS要简单很多，自带Rest API。对于中小型文件效率非常高，但是单卷最大容量被程序限制到30G，建议存储文件以100MB以内为主。
Ceph
Ceph是Red Hat旗下一个成熟的分布式文件系统，而且还是一个有企业级功能的对象存储生态环境。该系统具备高性能、高可用性、高可扩展性、实时存储性等特点。虽然ceph很强大，但是学习成本高、安装运维复杂。Ceph用C++编写，存储容量可轻松达到PB级别。
Ceph 实在不适合云环境，很难利用云的好处，但是 Kubernetes 在很多业务中需要共享文件系统，CephFS 还是被很多用户尝试了，不少也是从入门到放弃，因为运维门槛比较高，没有丰富分布式系统和存储系统运维经验的众多业务开发者很难搞定。
无中心化的最大优点是解决了中心节点自身的瓶颈，这也就是 ceph 号称可以无限向上扩容的原因。但由 Client 直接和 Server 通信，那么 Client 必须要知道，当对某个文件进行操作时，它该访问集群中的哪个节点。ceph 提供了一个很强大的原创算法来解决这个问题——CRUSH 算法。
Ceph有四部分组成：
基础存储系统RADOS
Ceph的最底层是RADOS（分布式对象存储系统），它具有可靠、智能、分布式等特性，实现高可靠、高可拓展、高性能、高自动化等功能，并最终存储用户数据。RADOS系统主要由Ceph OSD、Ceph Monitors两部分组成，Ceph OSD 的功能是存储数据，处理数据的复制、恢复、回填、再均衡，并通过检查其他OSD 守护进程的心跳来向 Ceph Monitors 提供一些监控信息。Ceph Monitor维护着展示集群状态的各种图表，包括监视器图、 OSD 图、归置组（ PG ）图、和 CRUSH 图。
基础库LIBRADOS
LIBRADOS层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS进行应用开发。RADOS是一个对象存储系统，因此，LIBRADOS实现的API是针对对象存储功能的。物理上，LIBRADOS和基于其上开发的应用位于同一台机器，因而也被称为本地API。应用调用本机上的LIBRADOS API，再由后者通过socket与RADOS集群中的节点通信并完成各种操作。
上层应用接口
Ceph上层应用接口涵盖了RADOSGW（RADOS Gateway）、RBD（Reliable Block Device）和Ceph FS（Ceph File System），其中，RADOSGW和RBD是在LIBRADOS库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。
应用层
应用层就是不同场景下对于Ceph各个应用接口的各种应用方式，例如基于LIBRADOS直接开发的对象存储应用，基于RADOSGW开发的对象存储应用，基于RBD实现的云主机硬盘等。
优势
高扩展性
Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。
特性丰富
Ceph支持对象存储、块存储和文件存储服务，故称为统一存储
缺点
运维复杂
无中心化架构设计，需要提前规划设计
性能不足
因为加入了日志导致数据实际上会双写
代码质量导致的稳定性问题
Ceph开始一个是博士为了完成论文写的demo，整体代码质量一般。
GlusterFS
GlusterFS 是由美国的 Gluster 公司开发的 POSIX 分布式文件系统（以 GPL 开源），它主要应用在集群系统中，具有高扩展性、高可用性、高性能、可横向扩展等特点，并且其没有元数据服务器的设计，让整个服务没有单点故障的隐患。该系统主要是为中大型文件设计的，存储容量可轻松达到PB。它存在扩容缩容影响服务器较多、遍历目录下文件耗时、小文件性能较差的缺点。2011 年被 Redhat 收购。
优势
数据文件最终以相同的目录结构保存在单机文件系统上，不用担心 GlusterFS 的不可用导致数据丢失。
没有明显的单点问题，可线性扩展。
对大量小文件的支持估计还不错。
缺点
这种结构是相对静态的，不容易调整，也要求各个存储节点有相同的配置，当数据或者访问不均衡时没法进行空间或者负载调整。故障恢复能力也比较弱，比如 Server1 故障时，Server2 上的文件就没办法在健康的 3 或者 4上增加拷贝保障数据可靠。
因为缺乏独立的元数据服务，要求所有存储节点都会有完整的数据目录结构，遍历目录或者做目录结构调整时需要访问所有节点才能得到正确结果，导致整个系统的可扩展能力有限，扩展到几十个节点时还行，很难有效地管理上百个节点。
ChubaoFS(新)
ChubaoFS（CFS）是京东开发的分布式文件系统和对象存储系统。其主要声称是云原生的分布式文件系统，主要用于k8s容器环境。
CFS是一个分布式的文件系统，支持多元数据服务器，支持posix接口（目前一些接口不支持），支持数据的append写和overwrite写模式，支持大文件和小文件的高性能读写。
由于研发的初衷主要用于docker容器环境，其主要需求如下：1）容器的持久化存储， 当容器销毁数据也可以存在。2）不同的容器可以并发访问同一个文件 3）存储资源不同的服务和应用程序共享。也就是需要一个可持久化，高并发访问，可共享访问的存储系统。
优势
支持overwrite的强一致性的数据复制。
分布式的元数据服务：相对于HDFS，MooseFS在大数据方面的优势。
缺点
Posix支持不全，rename还有问题，常用的文件锁需要支持。
目前CFS的元数据都缓存在内存中，而CFS的inode由于包含了大量layout信息。元数据比较大，会占大量的内存。这也可以通过增加元数据服务器的内存和节点数量来缓解。
没有数据迁移。新加节点会产生负责均衡。这对于大多数文件系统写少读多的情况也没太大问题。
社区活跃度不够，产品比较新，稳定性需要加强
JuiceFS(新)
JuiceFS 是一款面向云原生设计的高性能共享文件系统，在 Apache 2.0 开源协议下发布。提供完备的 POSIX 兼容性，可将几乎所有对象存储接入本地作为海量本地磁盘使用，亦可同时在跨平台、跨地区的不同主机上挂载读写。
JuiceFS 是一个分布式文件系统，元数据访问的延时取决于挂载点到服务端之间 1 到 2 个网络来回（通常 1-3 ms），数据访问的延时取决于对象存储的延时 (通常 20-100 ms)。顺序读写的吞吐量可以到 50MiB/s 至 2800MiB/s（查看 fio 测试结果），取决于网络带宽以及数据是否容易被压缩。
JuiceFS 内置多级缓存（主动失效），一旦缓存预热好，访问的延时和吞吐量非常接近单机文件系统的性能（FUSE 会带来少量的开销）。
除了普通挂载外，还支持以下几种方式：
Kuberenetes CSI 驱动：通过 Kubernetes CSI 驱动的方式将 JuiceFS 作为 Kubernetes 集群的存储层，详情请参考「Kubernetes 使用 JuiceFS」。
Hadoop Java SDK：方便在 Hadoop 体系中使用兼容 HDFS 接口的 Java 客户端访问 JuiceFS。详情请参考「Hadoop 使用 JuiceFS」。
S3 网关：通过 S3 协议访问 JuiceFS，详情请参考「配置 JuiceFS S3 网关」。
Docker Volume 插件：在 Docker 中方便使用 JuiceFS 的方式，详情请参考「Docker 使用 JuiceFS」。
WebDAV 网关：通过 WebDAV 协议访问 JuiceFS
优势
维护简单，开箱即用
适合云环境
缺点
严重依赖云厂商的存储可靠性
PolarFS(新)
PolarFS就是构建在新一代硬件上的分布式文件系统. 作为新一代SSD, NVMe SSD可以提供500K的iops, 平均延迟100us左右, 最新的3D XPoint SSD甚至可以将延迟降低到10us左右. 特别是最近Intel发布的SPDK开发套件, 可以bypass掉内核从而降低内核层面的软件开销. RDMA提供了低延迟的网络通信接口, 远远低于TCP/IP协议栈的网络接口. 应用程序通过API操作RDMA的三个队列, 分别是发送队列, 接收队列和完成队列. 发送和接收队列负责进行数据传输, 完成队列用来轮询数据传输完成的事件. 为了减少线程间切换的开销, PolarFS轮询完成队列.
定义：PolarFS 是为 PolarDB 设计的一个分布式文件系统，通过利用 RDMA、NVMe 等 bypass kernel 的技术，使 PolarFS 具有低时延、高吞吐、高可用等特性。
开源情况：目前开源的部分只包括Filesystem，而不包括下面的分布式块存储。论文中的polarfs可以理解成是分布式文件系统＋分布式块存储的总称。而当前开源的部分仅仅是上层的文件系统层。
PolarFS由4个部分组成, 分别是libpfs, PolarSwitch, ChunkServer和PolarCtrl. 从逻辑上说, PolarFS架构分成两大部分:
上层是文件系统层, 由libpfs和PolarCtrl共同完成文件系统层的抽象功能, 其中libpfs主要负责缓存元数据和向存储层发送IO请求, PolarCtrl主要负责处理元数据的读写请求(注: 这里说的元数据仅仅是与chunk server有关的元数据而不是文件系统层面的元数据).
下层是数据存储层, 由PolarSwitch, ChunkServer和PolarCtrl组成. 其中PolarSwitch负责缓存元数据, 并且转发IO请求, ChunkServer基于raft协议处理数据读写请求, PolarCtrl负责维护ChunkServer的状态和处理元数据的读写请求.
优势
性能好
延迟低
有许多技术创新夹持
缺点
依赖硬件，RDMA， PCIe SSD
不支持标准的文件接口
用户态文件接口
不支持跨AZ
主要是考虑延迟
互联网大厂存储跟踪
阿里
阿里云自研盘古存储平台，包括分布式文件系统（DFS），块存储（ECS云盘），对象存储（OSS）。另外PolarDB依赖的高性能分布式文件系统PolarFS。
腾讯
自研Ozone是Apache Hadoop社区推出的新一代分布式存储系统，能满足大量小文件的存储问题，解决Hadoop分布式文件系统在可扩展性上的缺陷，并支持百亿甚至千亿级文件规模的存储。
百度
早期百度分布式文件系统使用MooseFS，在此基础上研发了CCDB-NFS，解决MFS的问题，而后自研分布式文件系统BFS。
京东
京东自研分布式文件存储chubaoFS，整体性能优于Ceph，内部基于RDMA，SPDK等技术进行性能优化（这部分没有开源），整体性能接近PolarFS，目前已经服务ES和MySQL数据库。
网易
自研分布式块存储Curve，整体性能优于Ceph。
字节跳动
字节之前使用Ceph，后来（2018年以后）自研分布式文件存储（刚刚起步）。
美团
美团云自研分布式对象存储MetaDe nvB。
美团云自研分布式块存储Ursa。
滴滴
滴滴使用开源存储Ceph，并在此基础上深度优化。
本文为网络引用，对于分布式文件存储的知识整理，拓宽知识面，并非原创。