本文主要讲述FastDFS的整体架构、上传，下载基本原理。
一、FastDFS 介绍
FastDFS 是一个 C 语言实现的开源轻量级分布式文件系统，作者余庆(happyfish100)，支持Linux、FreeBSD、AID 等 Unix 系统，解决了大数据存储和读写负载均衡等问题，适合存储 4KB~500MB之间的小文件，如图片网站、短视频网站、文档、app 下载站等，UC、京东、支付宝、迅雷、酷狗等都有使用，其中 UC 基于 FastDFS 向用户提供网盘、广告和应用下载的业务的存储服务 FastDFS与 MogileFS、HDFS、TFS 等都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务.
二、FastDFS 架构
FastDFS 服务有三个角色：跟踪服务器(tracker server)、存储服务器(storage server)和客户端(client)。
Tracker server功能
跟踪服务器，主要做调度工作，起到均衡的作用。
负责管理所有的 storage server和 group,每个 storage 在启动后会连接 Tracker，告知自己所属 group 等信息，并保持周期性心跳，Tracker 根据 storage 心跳信息，建立 group--->[storage server list]的映射表。
tracker 管理的元数据很少，会直接存放在内存;tracker 上的元信息都是由 storage 汇报的信息生成的，本身不需要持久化任何数据，tracker 之间是对等关系，因此扩展 tracker 服务非常容易，之间增加tracker 服务器即可。
所有 tracker 都接受 stroage 心跳信息，生成元数据信息来提供读写服务(与其他 Master-Slave 架构的优势是没有单点，tracker 也不会成为瓶颈，最终数据是和一个可用的Storage Server 进行传输的)
storage server功能
存储服务器，主要提供容量和备份服务。
以 group 为单位，每个 group 内可以包含多台 storage server，数据互为备份，存储容量空间以 group 内容量最小的 storage 为准，建议 group 内的 storage server 配置相同。
以 group 为单位组织存储能够方便的进行应用隔离、负载均衡和副本数定制；缺点是 group 的容量受单机存储容量的限制，同时 group 内机器坏掉，数据恢复只能依赖 group 内其他机器重新同步(坏盘替换，重新挂载重启 fdfs_storaged 即可)
多个 group 之间的存储方式有 3 种策略：round robin(轮询)、load balance(选择最大剩余空间的组上传文件)、specify group(指定 group 上传)
group 中 storage 存储依赖本地文件系统，storage 可配置多个数据存储目录，磁盘不做 raid，直接分别挂载到多个目录，将这些目录配置为 storage 的数据目录即可
storage 接受写请求时，会根据配置好的规则，选择其中一个存储目录来存储文件；为避免单个目录下的文件过多，storage 第一次启时，会在每个数据存储目录里创建 2 级子目录，每级 256个，总共 65536 个，新写的文件会以 hash 的方式被路由到其中某个子目录下，然后将文件数据直接作为一个本地文件存储到该目录中
总结：1.高可靠性：无单点故障 2.高吞吐性：只要 Group 足够多，数据流量是足够分散的
三、FastDFS上传原理
FastDFS 提供基本的文件访问接口，如 upload、download、append、delete 等
选择 tracker server
集群中 tracker 之间是对等关系，客户端在上传文件时可用任意选择一个 tracker
选择存储 group
当 tracker 接收到 upload file 的请求时，会为该文件分配一个可以存储文件的 group，目前支持选择 group 的规则为:
1. Round robin,所有 group 轮询使用
2. Specified group,指定某个确定的 group
3. Load balance,剩余存储空间较多的 group 优先
选择 storage server
当选定 group 后，tracker 会在 group 内选择一个 storage server 给客户端，目前支持选择
server 的规则为：
1. Round robin,所有 server 轮询使用(默认)
2. 根据 IP 地址进行排序选择第一个服务器(IP 地址最小者)
3. 根据优先级进行排序(上传优先级由 storage server 来设置,参数为 upload_priority)
选择 storage path(磁盘或者挂载点)
当分配好 storage server 后，客户端将向 storage 发送写文件请求,storage 会将文件分配一
个数据存储目录，目前支持选择存储路径的规则为：
1. round robin,轮询(默认)
2. load balance,选择使用剩余空间最大的存储路径
选择下载服务器
目前支持的规则为：
1. 轮询方式,可以下载当前文件的任一 storage server
2. 从源 storage server 下载
生成 file_id
选择存储目录后，storage 会生成一个 file_id，采用 Base64 编码，包含字段包括：storage server ip、文件创建时间、文件大小、文件 CRC32 校验码和随机数；每个存储目录下有两个 256*256个子目录，storage 会按文件 file_id 进行两次 hash，路由到其中一个子目录，，然后将文件已file_id 为文件名存储到该子目录下，最后生成文件路径：group 名称、虚拟磁盘路径、数据两级目录、file_id
group1 /M01/02/35 QdbxwtqzvgwseqXVNM.mp3
其中，组名：文件上传后所在的存储组的名称，在文件上传成功后由存储服务器返回，需要客户端自行保存
虚拟磁盘路径：存储服务器配置的虚拟路径，与磁盘选项 store_path*参数对应
数据两级目录：存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件
四、FastDFS同步原理
1. 新增 tracker 服务器数据同步问题
由于 storage server 上配置了所有的 tracker server，storage server 和 tracker server 之间的通信是由 storage server 主动发起的，storage server 为每个 tracker server 启动一个线程进行通信;在通信过程中，若发现该 tracker server 返回的本组storage server 列表比本机记录少，就会将该 tracker server 上没有的 storage server同步给该 tracker，这样的机制使得 tracker 之间是对等关系，数据保持一致
2. 新增 storage 服务器数据同步问题
若新增 storage server 或者其状态发生变化，tracker server 都会将 storage server列表同步给该组内所有 storage server；以新增 storage server 为例，因为新加入的storage server 会主动连接 tracker server，tracker server 发现有新的 storage server加入，就会将该组内所有的 storage server 返回给新加入的 storage server，并重新将该组的 storage server 列表返回给该组内的其他 storage server；
3. 组内 storage 数据同步问题
组内 storage server之间是对等的，文件上传、删除等操作可以在组内任意一台storage server 上进行。文件同步只能在同组内的 storage server 之间进行，采用 push 方式，即源服务器同步到目标服务器
A. 只在同组内的 storage server 之间进行同步
B. 源数据才需要同步，备份数据不再同步
C. 特例：新增 storage server 时，由其中一台将已有所有数据(包括源数据和备份数据)同步到新增服务器
storage server 的 7 种状态：
通过命令 fdfs_monitor /etc/fdfs/client.conf 可以查看 ip_addr 选项显示 storage
server 当前状态
INIT ： 初始化，尚未得到同步已有数据的源服务器
WAIT_SYNC ： 等待同步，已得到同步已有数据的源服务器
SYNCING ： 同步中
DELETED ： 已删除，该服务器从本组中摘除
OFFLINE ： 离线
ONLINE ： 在线，尚不能提供服务
ACTIVE ： 在线，可以提供服务
组内增加 storage serverA 状态变化过程：
1. storage server A 主动连接 tracker server，此时 tracker server 将 storage
serverA 状态设置为 INIT
2. storage server A 向 tracker server 询问追加同步的源服务器和追加同步截止时间点(当前时间)，若组内只有 storage server A 或者上传文件数为 0，则告诉新机器不需要数据同步，storage server A 状态设置为 ONLINE ；若组内没有 active状态机器，就返回错误给新机器，新机器睡眠尝试；否则 tracker 将其状态设置为WAIT_SYNC
3. 假如分配了 storage server B 为同步源服务器和截至时间点，那么 storage server B 会将截至时间点之前的所有数据同步给 storage server A，并请求 tracker 设置storage server A 状态为SYNCING；到了截至时间点后，storage server B向 storage server A 的同步将由追加同步切换为正常 binlog 增量同步，当取不到更多的 binlog时，请求 tracker 将 storage server A 设置为 OFFLINE 状态，此时源同步完成
4. storage server B 向 storage server A 同步完所有数据，暂时没有数据要同步时，
storage server B 请求 tracker server 将 storage server A 的状态设置为 ONLINE
5. 当 storage server A 向 tracker server 发起心跳时，tracker sercer 将其状态更
改为 ACTIVE，之后就是增量同步(binlog)
注释：1.整个源同步过程是源机器启动一个同步线程，将数据 push 到新机器，最
大达到一个磁盘的 IO，不能并发
2.由于源同步截止条件是取不到 binlog，系统繁忙，不断有新数据写入的情况，将会导致一直无法完成源同步过程
四、FastDFS下载原理
1、Client向Tracker发送获取目标文件的请求，参数为文件标识(卷名和文件名)；
2、Tracker返回指定卷下一台可用的Storage；
3、Client直接与目标Storage通讯完成文件下载；
参数形式如下：
volume0/M00/00/02/Cs8b8lFJIIyAH841AAAbpQt7xVI4715674
volume0：组名
M00：磁盘名
00/02：目录
Cs8b8lFJIIyAH841AAAbpQt7xVI4715674：文件名，采用base64编码，信息包含源storage server Ip、文件创建时间、文件大小、文件CRC32效验码和随机数
tracker选择volume内可读的storage规则：
首选文件名编码中包含的源头storage；
文件创建时间戳(文件名中包含)=storage被同步到的时间戳(binlog中包含) && (当前时间-文件创建时间) > 文件同步所需最大时间；
文件创建时间戳 < storage被同步到的时间戳；
(当前时间-文件创建时间戳) > 同步延迟阈值；
五、FastDFS的同步机制和同步延迟的解决
1、 文件同步延迟问题
FastDFS同组中的Storage Server的数据是同步的,Storage Server对组内除自己以外的每台服务器都会启动专门的线程根据binlog进行文件同步,binlog中只记录文件名,不记录文件内容.当组内新加入一台服务器时,由已有的一台Storage Server将己有的所有数据(包括源头数据和备份数据)全部同步给这台新服务器.文件上传至组内的一台Storage Server后再由这台Storage Server根据binlog同步给组内的其他服务器这种同步的方式为异步方式,异步方式带来了文件同步延迟的问题,新文件上传之后,在汕尾被同步过去的Storage serVer中下载该文件的时候就会出现文件找不到的现象
2、 FastDFS对文件同步延迟问题的解决
首先要知道的是,一个组中包含哪些Storage Server不是通过配置文件设定的,而是通过Tracker Server获取到的,Storage Server会启动一个单独的线程完成对一台Tracker Server的连接和定时报告, Storage Server主动向Tracker Server报告其状态信息,包括磁盘剩余空间,文件同步状况,文件上传下载次数等统计信息,另外,每台Storage Server都会定时向Tracker Server报告它向同组其他机器同步到的文件时间戳.当Tracker Server收到一台Storage Server发来的同步报告之后,他会依次找出该组中各个Storage Server被同步到的文件时间戳最小值,作为Storage Server的一个属性记录到内存中,根据上述情况FastDFS提供下面简单的解决方案:
当客户端请求下载文件时,优先选择源Storage Server下载文件即可,这可以在Tracker Server的配置文件中进行设置,对应的参数名为download_server
选择Storage Server的方式是轮流选择,当客户端询问Tracker Server有哪些Storage Server可以下载指定文件时,Tracker Server返回满足如下的四个条件之一
a.该文件上传到的源Storage Server,文件直接上传到该服务器上的
b.文件创建时间戳 < Storage Server被同步到的文件时间戳.这意味着当前文件已经被同步过来了
c.文件创建时间戳 = Storage Server 被同步到的文件时间戳 并且 (当前时间-文件创建时间戳) > 一个文件同步需要完成需要的最大时间
d.(当前时间-文件创建时间) > 文件同步延迟阈值,比如我们把阈值设置为一条,代表文件在一天之内肯定能完成同步
简而言之:就是所有的Storage Server都会向Stracker Server提交自己的状态信息和文件同步信息,当客户端来想Tracker发起下载请求时,Tracker Server会根据Storage Server提供的信息一定会返回给客户端一个 一定有完成同步的Storage Server的地址
六、文件合并原理
小文件合并存储主要解决的问题：
1. 本地文件系统 inode 数量有限，存储小文件的数量受到限制
2. 多级目录+目录里很多文件，导致访问文件的开销很大(可能导致很多次 IO)
3. 按小文件存储，备份和恢复效率低
海量小文件存储问题请参考：http://blog.csdn.net/liuaigui/article/details/9981135
http://blog.csdn.net/kidd_3/article/details/6909097
FastDFS 提供合并存储功能，默认创建的大文件为 64MB，然后在该大文件中存储很多小文件；大文件中容纳一个小文件的空间称作一个 Slot，规定 Slot 最小值为 256 字节，最大为 16MB，即小于 256 字节的文件也要占用 256 字节，超过 16MB 的文件独立存储;
为了支持文件合并机制，FastDFS生成的文件file_id 需要额外增加 16个字节；每个trunk file由一个 id 唯一标识，trunk file 由 group 内的 trunk server 负责创建(trunk server 是 tracker选出来的)，并同步到 group 内其他的 storage，文件存储合并存储到 trunk file 后，根据其文件偏移量就能从 trunk file 中读取文件
FastDFS 文件合并原理细节请参考：http://blog.csdn.net/hfty290/article/details/42026215#comments
————————————————————————————
以上内容来源网络，作者稍加整理而成，有侵权及时联系作者！
1403
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
