分布式文件系统FastDFS架构认知

FastDFS是一款类Google FS的开源分布式文件系统（应用级的分布式文件存储服务）。

FastDFS的设计理念

FastDFS是为互联网应用量身定作的分布式文件系统，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标。FastDFS的架构和设计理念有其独到之处，主要体如今轻量级、分组方式和对等结构三个方面。

轻量级

FastDFS只有两个角色：Tracker server和Storage server。Tracker server做为中心结点，其主要做用是负载均衡和调度。Tracker server在内存中记录分组和Storage server的状态等信息，不记录文件索引信息，占用的内存量不多。另外，客户端（应用）和Storage server访问Tracker server时，Tracker server扫描内存中的分组和Storage server信息，而后给出应答。由此能够看出Tracker server很是轻量化，不会成为系统瓶颈。

FastDFS中的Storage server在其余文件系统中一般称做Trunk server或Data server。Storage server直接利用OS的文件系统存储文件。FastDFS不会对文件进行分块存储，客户端上传的文件和Storage server上的文件一一对应。

在FastDFS中，客户端上传文件时，文件ID不是由客户端指定，而是由Storage server生成后返回给客户端的。文件ID中包含了组名、文件相对路径和文件名，Storage server能够根据文件ID直接定位到文件。所以FastDFS集群中根本不须要存储文件索引信息，这是FastDFS比较轻量级的一个例证。而其余文件系统则须要存储文件索引信息，这样的角色一般称做NameServer。其中mogileFS采用MySQL数据库来存储文件索引以及系统相关的信息，其局限性显而易见，mysql将成为整个系统的瓶颈。

FastDFS轻量级的另一个体现是代码量较小，代码行数不到5.2万行。

分组方式

FastDFS采用了分组存储方式。集群由一个或多个组构成，集群存储总容量为集群中全部组的存储容量之和。一个组由一台或多台存储服务器组成，同组内的多台Storage server之间是互备关系，同组存储服务器上的文件是彻底一致的。文件上传、下载、删除等操做能够在组内任意一台Storage server上进行。相似木桶短板效应，一个组的存储容量为该组内存储服务器容量最小的那个，因而可知组内存储服务器的软硬件配置最好是一致的。

采用分组存储方式的好处是灵活、可控性较强。好比上传文件时，能够由客户端直接指定上传到的组。一个分组的存储服务器访问压力较大时，能够在该组增长存储服务器来扩充服务能力（纵向扩容）。当系统容量不足时，能够增长组来扩充存储容量（横向扩容）。采用这样的分组存储方式，可使用FastDFS对文件进行管理，使用主流的Web server如Apache、nginx等进行文件下载。

对等结构

FastDFS集群中的Tracker server也能够有多台，Tracker server和Storage server均不存在单点问题。Tracker server之间是对等关系，组内的Storage server之间也是对等关系。传统的Master-Slave结构中的Master是单点，写操做仅针对Master。若是Master失效，须要将Slave提高为Master，实现逻辑会比较复杂。和Master-Slave结构相比，对等结构中全部结点的地位是相同的，每一个结点都是Master，不存在单点问题。

Tracker server之间相互独立，不存在直接联系。

客户端和Storage server主动链接Tracker server。Storage server主动向Tracker server报告其状态信息，包括磁盘剩余空间、文件同步情况、文件上传下载次数等统计信息。Storage server会链接集群中全部的Tracker server，向他们报告本身的状态。Storage server启动一个单独的线程来完成对一台Tracker server的链接和定时报告。须要说明的是，一个组包含的Storage server不是经过配置文件设定的，而是经过Tracker server获取到的。

不一样组的Storage server之间不会相互通讯，同组内的Storage server之间会相互链接进行文件同步。

Storage server采用binlog文件记录文件上传、删除等更新操做。binlog中只记录文件名，不记录文件内容。

文件同步只在同组内的Storage server之间进行，采用push方式，即源头服务器同步给目标服务器。只有源头数据才须要同步，备份数据并不须要再次同步，不然就构成环路了。有个例外，就是新增长一台Storage server时，由已有的一台Storage server将已有的全部数据（包括源头数据和备份数据）同步给该新增服务器。

Storage server中由专门的线程根据binlog进行文件同步。为了最大程度地避免相互影响以及出于系统简洁性考虑，Storage server对组内除本身之外的每台服务器都会启动一个线程来进行文件同步。

文件上传和下载的交互过程

文件上传流程

1. Client询问Tracker server上传到的Storage server；

2. Tracker server返回一台可用的Storage server，返回的数据为该Storage server的IP地址和端口；

3. Client直接和该Storage server创建链接，进行文件上传，Storage server返回新生成的文件ID，文件上传结束。

文件下载流程

1. Client询问Tracker server能够下载指定文件的Storage server，参数为文件ID（包含组名和文件名）；

2. Tracker server返回一台可用的Storage server；

3. Client直接和该Storage server创建链接，完成文件下载。