分布式文件系统之FastDFS

Posted 2021-04-24 Java码出未来

导语：

传统在我们做项目的时候，大多数都会涉及到文件的上传和下载，传统方式我们就在webapp目录下新建一个比如叫“file”的文件夹，比如我们上传一个图片到file文件夹下，这时我们通过浏览器访问我们项目file文件夹下的文件就能访问到我们上传的图片，这样文件的上传和下载就实现了。但是，随着项目的一点点的发展，我们越来越发现这种方式是不行的。

为什么不行呢？

当今，互联网行业正在强势兴起，而互联网项目就会涉及到高并发，那么怎么解决高并发？，这时，集群这种我们都知道的方式就出现了，而集群环境最起码得有两台服务器A和B，每个服务器各有一份Tomcat和工程war包，那么file文件夹也就有两份了。我们都知道，现在我们使用集群来提供服务，那么在请求到达Tomcat之前，一定会有一个负载均衡服务器（nginx），这时大家可能知道了，当我们上传一个文件到服务器A，而我们再次访问这个文件时，由于负载均衡服务器的存在，我们可能访问不到了，不能做到服务器之间文件的同步，当我们服务器增多时尤为明显，那么怎么解决呢？相信大家都知道，大家在一些项目中可能就是这么做的，那就是搭建一个文件服务器，就放我们上传的文件，之后再搭建一个http服务器（nginx），这时我们的Tomcat集群就不会出现之前我说的问题了，因为文件服务器上所有的文件是被我们所有项目服务器所共用的。但是这样又暴露一些问题，比如：现在购物网站（天猫，京东等），会发现，上面大大小小的图片都是上万张，或者上百万张，我们的文件服务器的容量很快就会满，但很明显，这时不行的，加入硬盘容量不是问题，那么文件服务器宕机了又怎么办，或者说硬盘坏掉了又怎么办，坏掉之后里面的文件怎么恢复？，就算文件服务器是集群，但是他们的IP又是不一样的，那么上传文件代码就会改，而且可能会消耗大量的工作量，这不是我们的初衷。这些都是我们互联网项目要面对的问题，这时分布式文件系统就应时而生。

目前，分布式文件系统有很多，例如：FastDFS、HDFS、MogileFS等等，这里我们不对比各种分布式文件系统，今天我们说一说FastDFS。

---

FastDFS简介:

FastDFS是阿里巴巴开源的一款轻量级的，并且天生就是分布式设计的文件系统，源代码有C语言开发，他解决了大数据量文件存储和读写分离，以及高并发负载均衡，备份容灾，动态扩容等等上面我们所提到的问题，特别适合大中型网站使用，用来存储资源文件，如：图片，文档，音频，视频等。

FastDFS交互过程：

FastDFS的架构图：

如下图所示:

从上图可以看出：

FastDFS主要有三大部分，客户端Client、服务端Tracker 、服务端Storage

Tracker叫做追踪器或者调度器：因为客户端请求来时首先经过Tracker，由Tracker根据某种策略进行调度最终由Storage完成文件的上传和下载。Tracker负责调度并在访问上起到负载均衡和管理集群的作用，并记录Storage的状态，其自身也可以实现集群，每个节点是平等的。

Storage叫做存储节点或者存储服务器：他的作用是文件的存储，但他自身并没有实现自己的文件系统二是利用操作系统的文件系统来管理文件。它分为多个组，每个组之间保存的文件是不同的。每个组内部可以有多个成员，成员内部保存的内容是一样的，并且地位也是一样的，没有主次概念。

上传流程：

client通过询问Tracker上传文件到Storage(存储服务器)生成文件ID并返回给客户端，此文件ID用于以后访问该文件时所使用。包括：组名，虚拟磁盘路径，上文提到的两级目录，上传成功后所叫文件名。

例如：group1/M00/00/00/rBsCZlqXqmCAHkUUAABtk5IPvws380.jpg

组名：文件上传后所在的storage组名称，在文件上传成功后由存储服务器返回，需要客户端自行保存。

虚拟磁盘路径：storage配置的虚拟路径，与配置文件中磁盘选项store_path*对应。

 数据两级目录：storage存储服务器在每个虚拟磁盘路径下面都创建了两级目录，用于存储数据文件。

下载流程：

右上图可知，client以文件上传时得到的文件ID去询问Tracker找到Storage之后直接和Storage进行通信完成文件的下载。

---

今天就写到这里，下一篇将会说一说FastDFS文件服务器的搭建。