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代理到不同的group
• group的容量收到单机存储的限制，如果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 2
store_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 文件上传的优先级，默认值为10
upload_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 选择该文件上传的那台服务器，也叫做源storage
download_server = 0

5、文件同步原理

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

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

6、文件删除

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