1、架构图解析

客户端(client)

作为请求的发起方，也就是上传下载等请求的发起方。

跟踪服务器(tracker server)

主要任务是调度和负载均衡作用。内存中存储了集群中所有storage server的group和状态信息不记录文件的索引信息，主要存储一些元数据信息(完全由storage提供给)，占用内存很少tracker根据storage的心跳信息建立group和storage服务列表的映射关系因为元数据完全由storage提供，因此不需要持久化任何数据，所以tracker无状态，各个节点对等，非常容易扩展

存储服务器(storage server)

真正存储数据的服务器，文件和文件的元数据信息都保存在storage中，storage本身没有实现文件系统，而是直接使用操作系统调度管理文件storage以组(group)或卷(volume)划分集群，一个组可以由多个storage.这多个storage护卫备份，相当于数据是一样的。用于定制副本的数量存储空间将会以group内容量最小的storage为准，也就是短板效应。因为互为备份，超过最小空间就没办法备份了不同数据放在不同的组就能实现数据隔离，同时还可以通过nginx代理到不同的groupgroup的容量收到单机存储的限制，如果group内有机器坏掉，只能依赖group内的其他计起恢复，恢复时间会很长。storage依赖本地系统，可以配置多个数据存储目录。有10块磁盘的话，都可以挂载为数据目录为了避免同一个目录下文件过多，会创建两级子目录，默认每级256个，总过65535个文件夹。新上传的文件会通过hash方式路由到不同的子目录，然后将整个文件放在该目录。2、设计思想

轻量级

1、tracker server不持久化数据，节点对等，不会成为性能瓶颈2、不对文件分块，对应中小文件没有必要，不分块更加简单，高效3、文件Id包含了组名，我呢见相对路径，文件名可以直接定位文件位置。所以不需要文件索引4、代码量非常少，不到5.2万行

分组存储

1、集群由一个或多个组构成，集群容量为所有组的容量总和。2、同组内堕胎Storage互为备份，上传，下载，删除等可以在任何一台上操作。3、因为同组内的容量为容量最小的storage中。就是短板效应。容量不足可以横向增加组实现。4、下载时直接通过apache、nginx等web server即可。

对等结构

tracker server和storage server均不存在单点问题，节点都是对等的。3、文件上传原理

文件上传流程分析

1、如何选择tracker和group？

因为tracker server是支持集群，并且节点之间是对等的。

所以客户端在上传文件时，可以随意选择一个tracker server。

而tracker server接收到文件上传时，会通过配置策略为该文件分配一个group.

根据tracker.conf配置文件配置策略

# the method for selecting group to upload files# 0: round robin 轮询# 1: specify group 指定group, 与下面的store_group联合使用# 2: load balance, select the max free space group to upload file 负载均衡，选择一个空闲空间最大的group上传文件。默认策略store_lookup = 2# which group to upload file# when store_lookup set to 1, must set store_group to the group name# 如果store_lookup为1时，指定group的名称store_group = group2

2、选择group后，如何选择storage server ?

我们知道，选择group后，因为组内可能存在多个storage server, 并且互为备份，所以我们需要根据策略选择一个执行上传操作。

选择的策略通过tracker.conf配置storaged的选择

# which storage server to upload file# 0: round robin (default) 轮询，默认策略# 1: the first server order by ip address 通过ip排序的第一个# 2: the first server order by priority (the minimal) 通过优先级排序后的第一个（优先级在storage.conf中配置）# Note: if use_trunk_file set to true, must set store_server to 1 or 2store_server = 0

storage.conf中配置优先级

# the priority as a source server for uploading file.# the lower this value, the higher its uploading priority.# default value is 10 文件上传的优先级，默认值为10upload_priority=10

3、选择了storage后，我们有可能有多块数据盘，数据存放在哪个盘呢？

因为fastdfs直接使用操作系统的文件管理，容量收到操作系统限制，可以通过多挂载几块磁盘来增大存储空间。数据会根据策略存储在不同的磁盘上。

在storage.conf中如何配置多块磁盘呢

# path(disk or mount point) count, default value is 1, 磁盘或者挂载点的数量store_path_count=1# store_path#, based 0, if store_path0 not exists, it's value is base_path# the paths must be exist 多块磁盘配置多个存储路径，比如可以把store_path_count设置为2，将store_path1的注释打开，配置第二块磁盘的挂载目录store_path0=/home/fastdfs#store_path1=/home/yuqing/fastdfs2

4、数据有了存放的地方，会生成文件，文件名称有什么生成规则呢？

由storage的ip，文件创建时间，文件大小，文件crc32和一个随机数拼接而成，然后将该二进制串进行base64编码。组+目录+二级子目录+文件名.后缀 最终组成了文件的id。根据文件id可以直接定位文件，从而省去了一般文件存储需要存索引，通过索引定位文件内容。

4、文件下载原理

文件下载原理跟文件上传前面部分基本一样。只是选择哪个storage服务器下载文件的策略有些不一样。

在tracker.conf中专门为文件下载选择storage有一个配置项

# which storage server to download file# 0: round robin (default) 轮询，默认策略# 1: the source storage server which the current file uploaded to 选择该文件上传的那台服务器，也叫做源storagedownload_server = 0

因为同一个组内的storage是互为备份的，并且文件上传只会传到其中的一台。那么另外的服务器如何备份的呢？此时我们可能想到mysql的binlog日志。

fastdfs也有自己的binlog日志，在每个storage写入后，会将文件的元数据写入binlog日志storage也会记录组内其他storage对该文件的同步进度，以便异常情况能够实现增量同步进度通过时间戳记录，所以需要保证集群内的时钟同步同步进度同样会上报tracker，tracker在选择storage时会以进度为参考6、文件删除

文件删除和文件下载类似，只是下载是找到文件进行下载，删除是找到文件进行删除