搭建一个高性能的文件系统？不用他怎么行？

前言

今天给大家介绍的是FastDFS，一个开源的分布式文件系统，也是入职之后接触到的一个技术，由于公司项目业务需求，服务器里存了上亿量级的文件，所以使用了这么一项技术来存储这些文件，我也就随之开始了解这项技术，并且在这里和大家一起从0到1地开始了解它。

FastDFS介绍

FastDFS是一个以C语言开发的开源轻量级分布式文件系统，由阿里巴巴开发并开源。它对文件进行管理，功能包括：文件存储、文件同步、文件访问（上传、下载）等。解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

从0，自己的一些疑问：FastDFS过时了吗？

相信这也是很多同学想要问的一些问题，我还没有了解这个技术的时候，也同样有这样的疑问。

首先，现在有很多文件存储都会选择像七牛云、阿里云OSS等云服务，为什么要自己搭一套文件服务器增加维护成本呢？

其次，这并不是面试的热点，甚至在入职之前自己都没有接触过，甚至甚至，没有听说过，反倒是那些热门的技术，就算自己不主动去了解，当遇到的时候，大致也能知道是用来干嘛的。

那么我来说说我的理解，首先这个技术一定是还没有过时的，因为有些特殊的文件，因为信息安全顾虑等原因，不会选择公有云服务器，还有基于成本考虑，还有很多的中型互联网公司仍然是基于FastDFS来做自己的文件服务器的。另外，FastDFS作为一个分布式服务器，对轻量级、横向扩展、容灾备份、高可用、高性能、负载均衡都有着充分的考虑，依旧是一个文件服务器的不二之选。

那么为什么这样一项技术在如今却很少有人了解呢？

第一，我认为是需求所致，与其它业务相比，需要存储大量文件的业务相对之下还是比较少。如果文件存储量不大，按照传统的文件存储方式也不会有什么大的问题。

第二，现在有七牛云、阿里云OSS等公司提供对象存储，加之国内对于”上云“的追捧，就很少有人愿意自己搭服务器来做文件存储服务了。

当然对于一个技术人来说，各种各样的技术都得去学习，去适应，所以这篇文章希望可以帮助到感兴趣的同学，或是在工作中遇到高量级文件存储的同学，FastDFS是不错的选择。

传统文件存储方式

 

这是传统文件存储的方式，服务器上甚至不需要装任何的应用，只需要有SFTP服务，我们就可以写对应的代码，完成文件的CRUD。

这样的好处就是很方便，只需要一台机器，几行代码就能搞定文件的存储，但是这种方式的瓶颈和缺陷是很明显的。

首先，对于单体服务器来说，不考虑宕机的情况，单体文件服务器的带宽、磁盘容量是有上限的，那么当文件的体积占满了整个磁盘，我们只能选择扩展，但是这种单体服务器的方式，对于扩容就不太友好了，我们可以想想，难道我们要将原有的硬盘数据拷到一个更大的硬盘里，然后更换硬盘吗？

除了扩展以外，我们还需要面临一个问题，就是文件的查找，如果我们将所有文件都存放到一起，文件的数量如果到了一定的数量，就会面临磁盘IO速度瓶颈，不知道大家有没有遇到过下图中这种场景：

磁盘查询慢

如果我们需要在一个磁盘中找到某个文件，如果没有一个路径，或者路径下有很多文件，那么系统就会扫描磁盘，我们都知道，计算机体系结构中，关于速度，CPU>内存>硬盘，如果在生产环境下，真的需要存储大量的文件，假设存储的是用户的头像，那么用户每次打开APP，就需要等待个十几秒，自己的头像才会显示，那这个app估计没有人会使用吧。

有同学可能会说，那我们可以使用缓存啊，Redis的String类型是可以存储二进制数据的，而且Redis的String类型是一个Key对应一个值，查询效率会很高。的确这样在查询效率上可以达到，但是我们按照一张图片1M来计算，缓存又能存多少张图片呢？很显然这是一个十分昂贵的方式。

刚才我们考虑的都是服务器不宕机的状态，那么假设服务器宕机，那么我们就无法再提供数据存储服务；如果硬盘损坏，那么所有的数据都将丢失。

分布式文件系统

上文中说了传统文件存储方式的一些缺陷和弊端，这其实也是所有“单点“的弊端，无论是单点数据库、或者单点缓存、又或者是单点网关、单点注册中心，都在往分布式集群的方向发展。

总结一下，单点文件系统大致有这些弱点：

1. 磁盘容量存在瓶颈

2. IO速度存在瓶颈

3. 宕机、硬盘损坏数据丢失的风险

那么对于文件系统，我们如何使用分布式的方式来解决上述的缺陷呢？

解决磁盘容量瓶颈

上文中提到，当服务器文件系统存在磁盘容量瓶颈的原因是磁盘无法很方便的进行扩容，我们通常需要从硬件的层面来考虑扩容硬盘，如：更换大容量硬盘。

这种方式显然是不现实的，因为更换硬盘意味着我们需要关服务器，生产环境服务器关停三十秒都是很严重的生产事故，所以我们只能使用服务器横向扩展的方式，如果不能更换硬盘，那么我们就加服务器。

多服务器

这样我们就可以使用多台服务器共同来构成我们的文件系统了，每个文件服务器都是一个独立的节点，来存储不同的文件，根据特定的逻辑（这里需要自己写），来决定文件需要存储到哪个文件服务器中。这样即使服务器容量满了，我们也还可以继续横向扩展，理论上这样我们的文件系统是没有容量上限的。

解决IO速度瓶颈

刚才我们解决了单点文件服务器容量瓶颈，但是如果某台或者某几台服务器上的文件数量过多（查询效率降低），或者有大量的用户访问某一台服务器，还是会造成IO速度瓶颈。那么要如何解决这个问题。

我们可以想一想类似的案例——MySQL数据库。

众所周知，MySQL的数据也是存在硬盘中的，而我们在写SQL语句的时候，为了保证查询效率，通常会避免全表扫描，而是通过索引让其找到我们对应的那条数据。

所以我们也可以通过这种方式，避免全盘扫描或者大范围扫描，而我们都知道，操作系统对于文件是有一个天然的索引的，就是我们的多级目录。FastDFS也正是利用了这个来增加我们文件IO的效率的，这个暂且不提，下文中会展示。

解决宕机、硬盘损坏数据丢失的风险

能否解决这个问题才是分布式文件系统和单机文件系统最根本的区别，因为无论是单机磁盘容量瓶颈还是IO速度瓶颈，我们都可以通过增加硬件配置来解决ÿ