FastDFS分布式文件系统
一,简介
FastDFS是一个开源的轻量级 分布式文件系统,它对文件进行管理,功能包括:文件存储、文件同步、文件访问(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题。特别适合以中小文件(建议范围:4KB < file_size <500MB)为载体的在线服务,如相册网站、视频网站等等。使用纯C语言实现,支持Linux、FreeBSD、AIX等UNIX系统。同时FastDFS提供了Java,C和PHP等语言的客户端API,我们可以在应用服务端通过API操作文件系统。
二,原理分析
FastDFS包含两种角色:跟踪器Tracker和存储节点Storage,都可以单台或多台部署。
Storage存储节点的 分组(同一组内的存储节点文件完全一致,负载均衡分摊IO压力):
类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等进行文件下载。
文件上传流程:
流程描述:
1,当集群中不止一台跟踪器tracker server时,由于tracker之间是完全对等的,客户端在上传文件时可以任务选择其中的一台进行连接。
2,选择文件存储节点的分组group。当tracker接收到client上传文件的请求时,会为该文件分配一个可以存储该文件的group(存储节点组),当然客户端也可以手动指定存储该文件的组。自动分配的策略有1,Round robin(所有存储节点组group轮询选择);2,Load balance(剩余空间的多的group优先,存储节点Storage与跟踪器tracker之间建立socket长连接,实时向tracker跟踪器汇报空间大小等存储信息)。
3,选择分组下的一个存储节点Storage。当选定一个存储节点组group之后,接下来则需选择一个具体的存储节点Storage,具体策略有1,Round robin(该存储节点组group内轮询选择);2,First server ordered by ip(按ip排序);3,First server ordered by priority(按Storage存储节点设置的优先级排序,优先存储在级别高的Storage,该Storage存写binlog日志,然后该group内的其他存储节点基于binlog进行复制,保证最后group内所有存储节点文件完全一致)。
4,选择Storage path。当分配好存储节点Storage server之后,接下来则是选择存储路径,Storage 会为文件分配一个存储目录,支持如下规则1,Round robin(多个存储目录间轮询);2,剩余存储空间最多的优先。
5,生成全局唯一的字符串File ID。由Storage server ip + 文件创建时间 + 文件大小 + 文件crc32 +随机数,然后进行base64编码而成的字符串。
6,当选定存储目录之后,storage会为文件分配一个File ID,每个存储目录下有两级256*256的子目录,storage会按文件fileid进行两次hash(猜测),路由到其中一个子目录,然后将文件以fileid为文件名存储到该子目录下。
7,生成文件名。当文件存储到某个子目录后,即认为该文件存储成功,接下来会为该文件生成一个文件名,文件名由group、存储目录、两级子目录、File ID、文件后缀名(由客户端指定,主要用于区分文件类型)拼接而成。
文件下载流程:
文件下载流程分析:
跟upload file一样,在download file时客户端可以选择任意tracker server。client发送download请求给某个tracker,必须带上文件名信息,tracke从文件名中解析出文件的group、大小、创建时间等信息,然后为该请求选择一个storage用来服务读请求。由于group内的文件同步时在后台异步进行的,所以有可能出现在读到时候,文件还没有同步到某 些storage server上,为了尽量避免访问到这样的storage,tracker按照如下规则选择group内可读的storage。
选择读的storage规则:1. 该文件上传到的源头storage - 源头storage只要存活着,肯定包含这个文件,源头的地址被编码在文件名中。 2. 文件创建时间戳==storage被同步到的时间戳 且(当前时间-文件创建时间戳) > 文件同步最大时间(如5分钟) - 文件创建后,认为经过最大同步时间后,肯定已经同步到其他storage了。 3. 文件创建时间戳 < storage被同步到的时间戳。 - 同步时间戳之前的文件确定已经同步了 4. (当前时间-文件创建时间戳) > 同步延迟阀值(如一天)。 - 经过同步延迟阈值时间,认为文件肯定已经同步了。
三, HTTP访问支持
FastDFS的tracker和storage都内置了http协议的支持,客户端可以通过http协议来下载文件,tracker在接收到请求时,通 过http的redirect机制将请求重定向至文件所在的storage上;除了内置的http协议外,FastDFS还提供了通过 apache或nginx扩展模块下载文件的支持。
四,分布式文件系统对比
FastDFS与HDFS,TFS等特性比较。TFS是淘宝使用的分布式文件系统,用于海量小文件的存储,但使用和部署过于复杂,不够轻量化。HDFS是Hadoop分布式计算使用的文件系统,主要解决并行计算中分布式存储数据的问题。其单个数据文件通常很大,采用了分块(切分)存储的方式。
已有 0 人发表留言,猛击->> 这里<<-参与讨论
ITeye推荐