FastDFS分布式文件系统

本文转载自https://mp.weixin.qq.com/s/7wcEMzVy7gbiOBmIksG0WA

国内知名的系统级开源软件凤毛菱角，FastDFS就是其中的一个，其用户包括我们所熟知的支付宝、京东商城、迅雷、58同城、赶集网等等，它是个人所开发的软件，作者是余庆。

这篇文章包括接下来两篇文章仅是学习FastDFS的一些设计思想，学习它怎么实现高效、简洁、轻量级的一个系统的。

我们已经进入互联网时代，互联网给我们的生活带来便捷的同时，也给我们带来了诸多挑战。

对于海量文件的存储，一个机器不够，那么就用多台机器来存储。

如果一个文件只存储一份，那么如果存储这个文件的机器坏掉了，文件自然就丢失了，解决办法就是将文件进行备份，相信大多数人都有备份重要文件的习惯。FastDFS也是如此，为了防止单点的失败，肯定是需要冗余备份的。

FastDFS把应用服务器分为若干个组，每一组里面可以有多台机器（一般采用3台），每一台机器叫做存储服务器（storage server）。同一组内之间的数据是互为备份的，也就是说用户把文件传到任一服务器，都会在同组内其它两个服务器进行备份，因此一个组的存储空间大小是由该组内存储空间最小的那台机器是一样的（和木桶原理一样）。为了不造成存储空间的浪费，同一个组内的三台机器最好都一样。

每个存储服务器（storage server）的存储就够又是怎样的呢？展开来看，它可以分为多个目录，每个目录以M开头，用00、01、02......来划分，一般无需划分这么多目录，只用一个目录就可以了。

在每个根目录下面又划分了两级目录。如图所示，在/data/fastdfs0下又划分出两级目录，每一级有256个目录，这样算下来总共就有65535个目录了。存储文件时，就是通过两次哈希来确定放在哪一个目录下面。

那么问题就来了，有这么多组，到底该选择哪个组的服务器进行存储呢？或者说，访问的时候到底访问哪一个组呢？

FastDFS提供的解决思路是引入一个跟踪服务器（tracker server），它用于记录每一个组内的存储服务器信息，存储信息是每个storage主动回报给tracker，有了这些信息之后，tracker就可以做调度工作了，看看谁的存储空间大，就把文件放过去。

FastDFS的特点：

• 组与组之间是相互独立的

• 同一个组内的storage server之间需要相互备份

• 文件存放到一个storage之后，需要备份到别的服务器

• tracker之间是不交互的

• 每个storgae server都需要向所有的tracker去主动报告信息

• tracker与tracker之间是不知道彼此的存在的