标签:
在生产中我们一般希望文件系统能帮我们解决以下问题,如:1.超大数据存储;2.数据高可用(冗余备份);3.读/写高性能;4.海量数据计算。最好还得支持多平台多语言,支持高并发。
由于单台服务器无法满足以上要求,这就迫使开发者不得不考虑使用其他方式解决此类问题。分布式文件系统就在这样迫切的需求下孕育而生。
今天为什么把标题定为“分布式文件系统”呢?是因为我想通过此次分享(FastDFS原理介绍),和大家去做更多关于分布式文件系统的研究和分享。我想这项研究应该会是一个“系列”性的专题。在本文之后还计划分享“FastDFS源码分析”,“FastDFS扩容及资源优化”。
——————————————————---------——————————————————————-
什么是FastDFS?
FastDFS是一个开源的轻量级分布式文件系统。它解决了大数据量存储和负载均衡等问题。特别适合以中小文件(建议范围:4KB < file_size <500MB)为载体的在线服务,如相册网站、视频网站等等。在UC基于FastDFS开发向用户提供了:网盘,社区,广告和应用下载等业务的存储服务。
FastDFS架构:
FastDFS服务端有三个角色:跟踪服务器(tracker server)、存储服务器(storage server)和客户端(client)。
ps:这样的架构具有以下特点:1.轻量级(相比GFS简化了master角色,不再管理meta数据信息)。2.对等结构。3.分组方式。
FastDFS协议:
FastDFS角色间是基于TCP/IP协议进行通信,协议包格式为:header + body。具体结构如图:
上传机制:
同步时间管理:
当一个文件上传成功后,客户端马上发起对该文件下载请求(或删除请求)时,tracker是如何选定一个适用的存储服务器呢?
其实每个存储服务器都需要定时将自身的信息上报给tracker,这些信息就包括了本地同步时间(即,同步到的最新文件的时间戳)。而tracker根据各个存储服务器的上报情况,就能够知道刚刚上传的文件,在该存储组中是否已完成了同步。同步信息上报如下图:
下载机制:
精巧的FID:
说到下载就不得不提文件索引(又称:FID)的精巧设计了。文件索引结构如下图,是客户端上传文件后存储服务器返回给客户端,用于以后访问该文件的索引信息。文件索引信息包括:组名,虚拟磁盘路径,数据两级目录,文件名。
ps:
快速定位文件:
知道FastDFS FID的组成后,我们来看看FastDFS是如何通过这个精巧的FID定位到需要访问的文件。
本次分享的主要内容包含:FastDFS各角色的任务分工/协作,文件索引的原理设计以及文件上传/下载操作的流程。通过此次学习我们对FastDFS有了初步的了解,如:
标签:
原文地址:http://www.cnblogs.com/myibm/p/5940828.html