fastdfs原理简析

FastDFS是什么？

1.它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。
2.特别适合以文件为载体的在线服务，如相册网站、视频网站、电商网站等等。特别适合以中小文件（建议范围：4KB < file_size <500MB）为载体的在线服务。
3.FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

FastDFS应用场景？

为什么要使用Nginx的扩展模块来访问存储的文件，原因有两个：
1.如果进行文件合并，那么不使用FastDFS的nginx扩展模块，是无法访问到具体的文件的，因为文件合并之后，多个小文件都是存储在一个trunk文件中的，在存储目录下，是看不到具体的小文件的。
2.如果文件未同步成功，那么不使用FastDFS的nginx扩展模块，是无法正常访问到指定的文件的，而使用了FastDFS的nginx扩展模块之后，如果要访问的文件未同步成功，那么会解析出来该文件的源存储服务器ip，然后将该访问请求重定向或者代理到源存储服务器中进行访问

FastDFS原理分析

FastDFS 系统有三个角色：跟踪服务器(Tracker Server)、存储服务器(Storage Server)和客户端(Client)。
Tracker Server：跟踪服务器

主要做调度工作，并对Storage Server起到负载均衡的作用；
负责管理所有的 storage server和 group，每个 storage 在启动后会连接 Tracker，告知自己所属 group等信息，并保持周期性心跳。
Tracker Server可以有多台，Tracker Server之间是相互平等关系同时提供服务Tracker Server不存在单点故障。客户端请求Tracker Server采用轮询方式，如果请求的Tracker无法提供服务则换另一个Tracker。

Storage Server：存储服务器

主要提供容量和备份服务；
以 group 为单位，不同group之间互相独立，每个 group 内可以有多台 storage server，数据互为备份。
采用分组存储方式的好处是灵活、可控性较强。比如上传文件时，可以由客户端直接指定上传到的组也可以由Tracker进行调度选择。
一个分组的存储服务器访问压力较大时，可以在该组增加存储服务器来扩充服务能力（纵向扩容）。当系统容量不足时，可以增加组来扩充存储容量（横向扩容）。

存储策略:
为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷
之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。在卷中增加服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服
务。当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。

Storage状态收集:
Storage Server会通过配置连接集群中所有的Tracker Server，定时向他们报告自己的状态，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。
storage server有7个状态，如下：
FDFS_STORAGE_STATUS_INIT :初始化，尚未得到同步已有数据的源服务器
FDFS_STORAGE_STATUS_WAIT_SYNC :等待同步，已得到同步已有数据的源服务器
FDFS_STORAGE_STATUS_SYNCING :同步中
FDFS_STORAGE_STATUS_DELETED :已删除，该服务器从本组中摘除（注：本状态的功能尚未实现）
FDFS_STORAGE_STATUS_OFFLINE :离线
FDFS_STORAGE_STATUS_ONLINE :在线，尚不能提供服务
FDFS_STORAGE_STATUS_ACTIVE :在线，可以提供服务
当storage server的状态为 FDFS_STORAGE_STATUS_ONLINE 时，当该storage server向tracker server发起一次heart beat时，tracker server将其状态更改为 FDFS_STORAGE_STATUS_ACTIVE 。

文件上传流程分析

先看第3步–选择存储的group
当tracker接收到upload file的请求时，会为该文件分配一个可以存储该文件的group，支持如下选择group的规则：
1.Round robin，所有的group间轮询
2.Specified group，指定某一个确定的group
3.Load balance，剩余存储空间多多group优先
第4步–选择storage server
当选定group后，tracker会在group内选择一个storage server给客户端，支持如下选择storage的规则：
1.Round robin，在group内的所有storage间轮询
2.First server ordered by ip，按ip排序
3.First server ordered by priority，按优先级排序（优先级在storage上配置）
第5步–选择storage path
当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录，支持如下规则（在storage配置文件可以通过配置store_path参数来设置，该参数可以设置多个，通过来区别）：
1.Round robin，多个存储目录间轮询
2.剩余存储空间最多的优先
下来就是选择两级目录生成文件的field
当选定存储目录之后，storage会为文件分配一个fileid，每个存储目录下有两级256*256的子目录，storage会按文件名称进行两次hash（猜测），路由到其中一个子目录，然后将文件以fileid为文件名存储到该子目录下。当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名，文件名由group、存储目录、两级子目录、文件名、文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成。

文件同步分析

写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage server写完文件后，会由后台线程将文件同步至同group内其他的storage server。

每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用
于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时
间戳的方式进行记录，所以最好能保证集群内所有server的时钟保持同步。
storage的同步进度会作为元数据的一部分汇报到tracker上，tracker在选择读storage的时候会以同步进度作为参考。

文件下载流程分析

选择可用的storage Server
client发送download请求给某个tracker，必须带上文件名信息，tracker从文件名中解析出文件的group、路径信息、文件大小、创建时间、源storage server ip等信息，然后为该请求选择一个storage用来服务读请求。
由于group内的文件同步是在后台异步进行的，所以有可能出现在读的时候，文件还没有同步到某些storage server上，为了尽量避免访问到这样的storage，tracker按照如下规则选择group内可读的storage：

该文件上传到的源头storage - 源头storage只要存活着，肯定包含这个文件，源头的地址被编码在文
件名中。
文件创建时间戳==storage被同步到的时间戳且(当前时间-文件创建时间戳) > 文件同步最大时间（如5分钟) - 文件创建后，认为经过最大同步时间后，肯定已经同步到其他storage了。
文件创建时间戳 < storage被同步到的时间戳。 - 同步时间戳之前的文件确定已经同步了
(当前时间-文件创建时间戳) > 同步延迟阀值（如一天）。 - 经过同步延迟阈值时间，认为文件肯定已经同步了

合并存储(重点)

在处理海量小文件问题上，文件系统处理性能会受到显著的影响，在读写次数（IOPS）与吞吐量（Throughput）这两个指标上会有不少的下降。主要需要面对如下几个问题：

元数据管理低效，磁盘文件系统中，目录项(dentry)、索引节点(inode)和数据(data)保存在存储介质的不同位置上。因此，访问一个文件需要经历至少3次独立的访问。这样，并发的小文件访问就转变成了大量的随机访问，而这种访问对于广泛使用的磁盘来说是非常低效的；
数据布局低效；IO访问流程复杂；因此一种解决途径就是将小文件合并存储成大文件，使用seek来定位到大文件的指定位置
来访问该小文件

FastDFS提供的合并存储功能，默认创建的大文件为64MB，然后在该大文件中存储很多小文件。大文件中容
纳一个小文件的空间称为一个Slot，规定Slot最小值为256字节，最大为16MB，也就是小于256字节的文件
也需要占用256字节，超过16MB的文件不会合并存储而是创建独立的文件。

Trunk文件合并存储空闲空间管理：
Trunk文件为64MB（默认），因此每次创建一次Trunk文件总是会产生空余空间，比如为存储一个10MB文件，创建一个Trunk文件，那么就会剩下接近54MB的空间（TrunkHeader 会24字节，后面为了方便叙述暂时忽略其所占空间），下次要想再次存储10MB文件时就不需要创建新的文件，存储在已经创建的Trunk文件中即可。另外当删除一个存储的文件时，也会产生空余空间。
在Storage内部会为每个store_path构造一颗以空闲块大小作为关键字的空闲平衡树，相同大小的空闲块保存在链表之中。每当需要存储一个文件时会首先到空闲平衡树中查找大于并且最接近的空闲块，然后试着从该空闲块中分割出多余的部分作为一个新的空闲块，加入到空闲平衡树中。例如：
要求存储文件为300KB，通过空闲平衡树找到一个350KB的空闲块，那么就会将350KB的空闲块分裂成两块，前面300KB返回用于存储，后面50KB则继续放置到空闲平衡树之中。
假若此时找不到可满足的空闲块，那么就会创建一个新的trunk文件64MB，将其加入到空闲平衡树之中，再次执行上面的查找操作。

TrunkServer:
假若所有的Storage都具有分配空闲空间的能力（upload文件时自主决定存储到哪个TrunkFile之中），那么可能会由于同步延迟导致数据冲突例如：
Storage-A：Upload一个文件A.txt 100KB，将其保存到000001这个TrunkFile的开头，与此同时，StorageB也接受Upload一个文件B.txt 200KB，将其保存在000001这个TrunkFile文件的开头，当Storage-B收到Storage-A的同步信息时，他无法将A.txt 保存在000001这个trunk文件的开头，因此这个位置已经被B.txt占用。为了处理这种冲突，引入了TrunkServer 概念，只有 TrunkServer 才有权限分配空闲空间，决定文件应该保存到哪个TrunkFile的什么位置。TrunkServer由Tracker指定，并且在心跳信息中通知所有的Storage。

Tracker-Leader选择TrunkServer:
在一个FastDFS集群之中，在开启合并存储时，为了分配空间引入了一个TrunkServer角色，该TrunkServer是该Group中的一个Storage，只是该Storage要负责为该组内的所有Upload操作分配空间。为了避免不同Tracker为该Group选择了不同的TrunkServer，此时引入了Tracker-Leader角色，也就是TrunkServer最终是由TrackerLeader来选择的，然后通知给该组内的所有Storage。