分布式文件系统FastDFS架构剖析 -
- ITeye技术网站
博客分类：
FastDFS是一款类Google FS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等UNIX系统。它只能通过专有API对文件进行存取访问，不支持POSIX接口方式，不能mount使用。准确地讲，Google FS以及FastDFS、 mogileFS、HDFS、TFS等类Google FS都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。
FastDFS的设计理念
FastDFS是为互联网应用量身定做的分布式文件系统，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标。和现有的类 Google FS分布式文件系统相比，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 上的文件一一对应。
众所周知，大多数网站都需要存储用户上传的文件，如图片、视频、电子文档等。出于降低带宽和存储成本的考虑，网站通常都会限制用户上传的文件大小，例如图片文件不能超过5MB、视频文件不能超过100MB等。我认为，对于互联网应用，文件分块存储没有多大的必要。它既没有带来多大的好处，又增加了系统的复杂性。FastDFS不对文件进行分块存储，与支持文件分块存储的DFS相比，更加简洁高效，并且完全能满足绝大多数互联网应用的实际需要。
在FastDFS中，客户端上传文件时，文件ID不是由客户端指定，而是由Storage server生成后返回给客户端的。文件ID中包含了组名、文件相对路径和文件名，Storage server可以根据文件ID直接定位到文件。因此FastDFS集群中根本不需要存储文件索引信息，这是 FastDFS比较轻量级的一个例证。而其他文件系统则需要存储文件索引信息，这样的角色通常称作NameServer。其中mogileFS采用 MySQL数据库来存储文件索引以及系统相关的信息，其局限性显而易见，MySQL将成为整个系统的瓶颈。
FastDFS轻量级的另外一个体现是代码量较小。最新的V2.0包括了C客户端API、FastDHT客户端API和PHP extension等，代码行数不到5.2万行。
类Google FS都支持文件冗余备份，例如Google FS、TFS的备份数是3。一个文件存储到哪几个存储结点，通常采用动态分配的方式。采用这种方式，一个文件存储到的结点是不确定的。举例说明，文件备份数是3，集群中有A、B、C、D四个存储结点。文件1可能存储在A、B、C三个结点，文件2可能存储在B、C、D三个结点，文件3可能存储在A、B、D三个结点。
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，不存在单点问题。
FastDFS的架构
图1展示的是FastDFS的系统架构。
图1 FastDFS的系统架构
从图1可以看出，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对组内除自己以外的每台服务器都会启动一个线程来进行文件同步。
文件同步采用增量同步方式，系统记录已同步的位置（binlog文件偏移量）到标识文件中。标识文件名格式：{dest storage IP}_{port}.mark，例如：192.168.1.14_23000.mark。
文件上传和下载的交互过程
接下来我们一起看一下文件上传和下载的交互过程。文件上传和下载流程分别如图2、图3所示。文件上传流程的步骤如下：
图2 文件上传流程
图3 文件下载流程
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建立连接，完成文件下载。
文件同步延迟问题的提出
客户端将一个文件上传到一台Storage server后，文件上传工作就结束了。由该Storage server根据binlog中的上传记录将这个文件同步到同组的其他Storage server。这样的文件同步方式是异步方式，异步方式带来了文件同步延迟的问题。新上传文件后，在尚未被同步过去的Storage server上访问该文件，会出现找不到文件的现象。FastDFS是如何解决文件同步延迟这个问题的呢？
文件的访问分为两种情况：文件更新和文件下载。文件更新包括设置文件附加属性和删除文件。文件的附加属性包括文件大小、图片宽度、图片高度等。 FastDFS中，文件更新操作都会优先选择源Storage server，也就是该文件被上传到的那台Storage server。这样的做法不仅避免了文件同步延迟的问题，而且有效地避免了在多台Storage server上更新同一文件可能引起的时序错乱的问题。
那么文件下载是如何解决文件同步延迟这个问题的呢？
要回答这个问题，需要先了解文件名中包含了什么样的信息。Storage server生成的文件名中，包含了源Storage server的 IP地址和文件创建时间等字段。文件创建时间为UNIX时间戳，后面称为文件时间戳。从文件名或文件ID中，可以反解出这两个字段。
然后我们再来看一下，Tracker server是如何准确地知道一个文件已被同步到一台Storage server上的。前面已经讲过，文件同步采用主动推送的方式。另外，每台storage server都会定时向tracker server报告它向同组的其他 storage server同步到的文件时间戳。当tracker server收到一台storage server的文件同步报告后，它会依次找出该组内各个storage server（后称作为S）被同步到的文件时间戳最小值，作为S的一个属性记录到内存中。
FastDFS对文件同步延迟问题的解决方案
下面我们来看一下FastDFS采取的解决方法。
一个最简单的解决办法，和文件更新一样，优先选择源Storage server下载文件即可。这可以在Tracker server的配置文件中设置，对应的参数名为download_server。
另外一种选择Storage server的方法是轮流选择（round-robin）。当Client询问Tracker server有哪些 Storage server可以下载指定文件时，Tracker server返回满足如下四个条件之一的Storage server：
该文件上传到的源Storage server，文件直接上传到该服务器上的；
文件创建时间戳 & Storage server被同步到的文件时间戳，这意味着当前文件已经被同步过来了；
文件创建时间戳=Storage server被同步到的文件时间戳，且（当前时间—文件创建时间戳） & 一个文件同步完成需要的最大时间（如5分钟）；
（当前时间—文件创建时间戳） & 文件同步延迟阈值，比如我们把阈值设置为1天，表示文件同步在一天内肯定可以完成。
看了上面的介绍，你是否认为FastDFS比较简洁高效呢？原雅虎同事——一位比较资深的系统架构师听完FastDFS介绍后，作出这样的评价：“FastDFS是穷人的解决方案”。他的意思是说FastDFS把简洁和高效做到了极致，非常节约资源，中小网站完全用得起，这是对FastDFS 的极大认可和褒奖。
FastDFS从2008年7月发布至今，已推出31个版本，后续完善和优化工作正在持续进行中。目前已有多家公司在生产环境中使用FastDFS，相信通过我们的不懈努力，FastDFS一定会越来越好！
作者简介：
余庆，现在淘宝网Java中间件团队从事Java基础平台研发工作，有10年互联网开发和架构经历，曾担任新浪网开发工程师、雅虎中国架构师。开源分布式文件系统FastDFS和分布式哈希系统FastDHT的作者，对分布式数据存储架构有比较深入的研究。
wangjc_opal
浏览: 107093 次
来自: 上海
var bankCode=$(&#bankCodeX ...
讲的非常好
Good，可以的
classEcityLoggerManagerstatic U ...
good, 不错FastDFS（5）
& & FastDFS是国人开发的一款分布式文件系统，目前社区比较活跃。系统中存在三种节点：Client、Tracker、Storage，在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10，提升简单负载均衡、并发IO的性能、及数据的冗余备份；同时通过线性的添加新的逻辑存储组，从容实现存储容量的线性扩容。
& & 文件下载上，除了支持通过API方式，目前还提供了apache和nginx的插件支持，同时也可以不使用对应的插件，直接以Web静态资源方式对外提供下载。目前FastDFS(V4.x)代码量大概6w多行，内部的网络模型使用比较成熟的libevent三方库，具备高并发的处理能力。
1）在上述介绍中Tracker服务器是整个系统的核心枢纽，其完成了访问调度(负载均衡)，监控管理Storage服务器，由此可见Tracker的作用至关重要，也就增加了系统的单点故障，为此FastDFS支持多个备用的Tracker，虽然实际测试发现备用Tracker运行不是非常完美，但还是能保证系统可用。
2）在文件同步上，只有同组的Storage才做同步，由文件所在的源Storage服务器push至其它Storage服务器，目前同步是采用Binlog方式实现，由于目前底层对同步后的文件不做正确性校验，因此这种同步方式仅适用单个集群点的局部内部网络，如果在公网上使用，肯定会出现损坏文件的情况，需要自行添加文件校验机制。
3）支持主从文件，非常适合存在关联关系的图片，在存储方式上，FastDFS在主从文件ID上做取巧，完成了关联关系的存储。
1）系统无需支持POSIX(可移植操作系统)，降低了系统的复杂度，处理效率更高
2）支持在线扩容机制，增强系统的可扩展性
3）实现了软RAID，增强系统的并发处理能力及数据容错恢复能力
4）支持主从文件，支持自定义扩展名
5）主备Tracker服务，增强系统的可用性
1）不支持断点续传，对大文件将是噩梦(FastDFS不适合大文件存储)
2）不支持POSIX通用接口访问，通用性较低
3）对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略
4）同步机制不支持文件正确性校验，降低了系统的可用性
5）通过API下载，存在单点的性能瓶颈
问题分析：
& & 从FastDFS的整个设计看，基本上都已简单为原则。比如以机器为单位备份数据，简化了tracker的管理工作；storage直接借助本地文件系统原样存储文件，简化了storage的管理工作；文件写单份到storage即为成功、然后后台同步，简化了写文件流程。但简单的方案能解决的问题通常也有限，FastDFS目前尚存在如下问题:
数据安全性：
& & 写一份即成功：从源storage写完文件至同步到组内其他storage的时间窗口内，一旦源storage出现故障，就可能导致用户数据丢失，而数据的丢失对存储系统来说通常是不可接受的。
& &缺乏自动化恢复机制：当storage的某块磁盘故障时，只能换存磁盘，然后手动恢复数据；由于按机器备份，似乎也不可能有自动化恢复机制，除非有预先准备好的热备磁盘，缺乏自动化恢复机制会增加系统运维工作。
& &数据恢复效率低：恢复数据时，只能从group内其他的storage读取，同时由于小文件的访问效率本身较低，按文件恢复的效率也会很低，低的恢复效率也就意味着数据处于不安全状态的时间更长。
& &缺乏多机房容灾支持：目前要做多机房容灾，只能额外使用工具来将数据同步到备份的集群，无自动化机制。
存储空间利用率：
& &&单机存储的文件数受限于inode数量
& &每个文件对应一个storage本地文件系统的文件，平均每个文件会存在block_size/2的存储空间浪费。
文件合并存储能有效解决上述两个问题，但由于合并存储没有空间回收机制，删除文件的空间不保证一定能复用，也存在空间浪费的问题
负载均衡：
& & group机制本身可用来做负载均衡，但这只是一种静态的负载均衡机制，需要预先知道应用的访问特性；同时group机制也导致不可能在group之间迁移数据来做动态负载均衡
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：6142次
排名：千里之外
原创：15篇查看: 11030|回复: 8
注册时间最后登录在线时间156 小时阅读权限90积分16029帖子主题精华0UID9647
194注册时间最后登录在线时间156 小时阅读权限90积分16029帖子主题精华0UID9647
文件类型大多为图片, 所以大小不会大于5m吧, 然后量会很大, 做电子商务的, 图片很多
相对哪个更合适些, 同时考虑到集成, 部署, 扩展, 维护的简易性
注册时间最后登录在线时间548 小时阅读权限150积分7435帖子主题精华3UID1215
犯强汉者，虽远必诛！
注册时间最后登录在线时间548 小时阅读权限150积分7435帖子主题精华3UID1215
在性能角度来说，还是fastdfs性能比moosefs要高！fastdfs 类似于mogilefs，每个操作都要用到api来操作，包括你在其上看图片。moosefs 是个缺点和优点并存的文件系统，符合posix标准，跟在NFS上操作没啥区别！
&-sina_sign,,1-&
注册时间最后登录在线时间156 小时阅读权限90积分16029帖子主题精华0UID9647
注册时间最后登录在线时间156 小时阅读权限90积分16029帖子主题精华0UID9647
你是不是在暗示我用fdfs
注册时间最后登录在线时间548 小时阅读权限150积分7435帖子主题精华3UID1215
犯强汉者，虽远必诛！
注册时间最后登录在线时间548 小时阅读权限150积分7435帖子主题精华3UID1215
根据自己环境的需要！
&-sina_sign,,1-&
注册时间最后登录在线时间156 小时阅读权限90积分16029帖子主题精华0UID9647
注册时间最后登录在线时间156 小时阅读权限90积分16029帖子主题精华0UID9647
研究了下, 束缚太多, 继续研究下别的, 不行的话再回头来用它
哈哈, 我不喜欢被动的接受, 命名, 目录, 环境需求....
注册时间最后登录在线时间11 小时阅读权限50积分974帖子主题精华0UID3297
高级会员, 积分 974, 距离下一级还需 1026 积分
注册时间最后登录在线时间11 小时阅读权限50积分974帖子主题精华0UID3297
使用fastDFS吧
注册时间最后登录在线时间21 小时阅读权限70积分9772帖子主题精华0UID15270
金牌会员, 积分 9772, 距离下一级还需 228 积分
注册时间最后登录在线时间21 小时阅读权限70积分9772帖子主题精华0UID15270
用fastdfs吧，学习成本低，够用了
如是想深入学习分布式存储技术，推荐看看google的一个大神发的那个论文
研究下GFS和HDFS，给自己冲冲电，嘎嘎
注册时间最后登录在线时间156 小时阅读权限90积分16029帖子主题精华0UID9647
注册时间最后登录在线时间156 小时阅读权限90积分16029帖子主题精华0UID9647
那论文是不错
注册时间最后登录在线时间2 小时阅读权限1积分38帖子主题精华0UID3034
新手上路, 积分 38, 距离下一级还需 12 积分
注册时间最后登录在线时间2 小时阅读权限1积分38帖子主题精华0UID3034
看你实际操作和应用了
moosefs性能比较差，高并发写入海量数据的时候就是个噩梦
fastdfs不支持fuse
Medal No.9
Powered byrfyiamcool 的BLOG
用户名：rfyiamcool
文章数：423
评论数：2196
访问量：1338597
注册日期：
阅读量：5863
阅读量：12276
阅读量：364547
阅读量：1059790
51CTO推荐博文
前言： & &周天被朋友拖住了，他说最近要实现一个文件分享的网站，一个是图片，一个是特定的文件，比如压缩包、pdf这类的。 他是做idc的，手里的资源还是不少的， 想通过文件分享网站来导入点所谓的流量。哥年轻时跟他搞过一个php的淘宝图片站，结果有个卖衣服的站点，流量很大，成本太高了，再说也没钱再次投入了，也就放弃 ~ & 没赚多少钱，倒是赔给那几个淘宝卖家100多块钱。 &想起往事，还算有趣的 ~现在的我以前不是当初菜鸟的我了，google了半天，从别地方，拔下来一个html模板，而且还是很高端的样子，后端是用pyton的tornado框架改了改，跑了几个实例都是没有问题的 ~实现的方法简单的上传建立表单，文件上传，然后写如到tmp目录的下，调用自己写的python fastdfs模块上传文件。也可以放到目录后，用inotify 来做文件的监控，触发文件后，就上传到fastdfs分布式存储里面。下载可以通过fastdfs本身的web做下载连接，但是为了更高的性能，推荐使用nginx fastdfs模块来实现的下载，给朋友也是这么做的。（还没有正式的上线，嘿嘿）subprocess 调用系统的fastdfs客户端上传文件：/usr/local/bin/fdfs_upload_file
&config_file& &local_filename&tornado的文件上传apidef post(self):
upload_path=os.path.join(os.path.dirname(__file__),'files')
#文件的暂存路径
file_metas=self.request.files['file']
#提取表单中‘name’为‘file’的文件元数据
for meta in file_metas:
filename=meta['filename']
filepath=os.path.join(upload_path,filename)
with open(filepath,'wb') as up:
#有些文件需要已二进制的形式存储，实际中可以更改
up.write(meta['body'])
self.write('finished!')
app=tornado.web.Application([
(r'/file',UploadFileHandler),
])一般来说，上传后得到的文件名字，是一串hash，和以前的名字比起来不太一样。 & & &举个例子，我明明上传的文件时 xiaorui.jpg，结果fastdfs接口给我返回的是 一堆的hash ，这是在让人有点小郁闷。
& & 我这里还只是图片的应用，后期文件功能出来后，让人看到的都是hash，你都不能通过hash想象出他的文件。查看了uc那边的技术博客，扩展了一套简单的路子。这边用到的是 & nginx tornado &jquery bootstrap1. & 应用系统在上传文件到FastDFS成功时将原始文件名和“文件索引（FID）”保存下来，我这里会记录在redis里面。2. &在浏览器下载的时用Nginx的域名和FID拼出url，在url后面增加一个参数，指定原始文件名。例如： 3. 在Nginx上进行如下配置，这样Nginx就会截获url中的参数attname，在Http响应头里面加上字段 Content-Disposition “filename=$arg_attname”。location /group1/M00 {
root /data/store/data1;
if ($arg_attname ~ "^(.*).cc") {
add_header Content-Disposition "filename=$arg_attname";
ngx_fastdfs_
location /group2/M00 {
root /data/store/data2;
if ($arg_attname ~ "^(.*).cc") {
add_header Content-Disposition "filename=$arg_attname";
ngx_fastdfs_
}4. & 浏览器发现响应头里面有Content-Disposition “filename=$arg_attname”时，就会把文件名显示成filename指定的名称。大家可以测试下，原来就是给用户的url多出一个get参数，用nginx识别到之后，插入到header头信息Content-Disposition 协议。到半夜为止，和哥们一块已经实现了该项目的大部门网络框架，当然前端的nginx是用kvm虚拟机做的，毕竟7层对io需求不是很大。针对nginx做的轮训是在代码层面实现的。好了，就这样吧。 这fastdfs真是个好东西 ！ 特别适合以文件为载体的在线服务，如图片站，文件分享等等 ！本文出自 “” 博客，谢绝转载！
了这篇文章
类别：┆阅读(0)┆评论(0)
08:55:24 09:15:36 09:40:31 09:48:21 13:20:36 21:51:25 09:24:51 11:16:10