fastdfs笔记.docx

1、fastdfs笔记FastDFS ：跟踪服务器崩溃怎么处理FastDFS:同步延迟的问题不能下载4.06及以上版，因为不支持内置http,所以安装模式完全不一样分布式系统软件HadoopFastDFSMogileFsLustreCodaFastDFS通过修改配置文件就可实现负载均衡主要是定位和应用场合不一样。hadoop的文件系统HDFS主要解决并行计算中分布式存储数据的问题。其单个数据文件通常很大，采用了分块（切分）存储的方式；FastDFS主要用于大中网站，为文件上传和下载提供在线服务。所以在负载均衡、动态扩容等方面都支持得比较好，FastDFS不会对文件进行分块（切分）存储。一台服务器可

2、以装多个组(group)但不能装同组的多个Storage,日志会报错误，意思是说，192.168.10.2如果有storage1（192.168.10.1）对应group1,那么storage2（192.168.10.2）再对应group1，会让group同时对应多个storage,而且这两个storage是处于同台服务器，这样就冲突了，所以这两个同group的storage必须处于不同该服务器FastDFS是一个开源的轻量级分布式文件系统，由跟踪服务器（tracker server）、存储服务器（storage server）和客户端（client）三个部分组成，主要解决了海量数据存储问题，

3、特别适合以中小文件（建议范围：4KB file_size storage server list的映射表。Tracker需要管理的元信息很少，会全部存储在内存中；另外tracker上的元信息都是由storage汇报的信息生成的，本身不需要持久化任何数 据，这样使得tracker非常容易扩展，直接增加tracker机器即可扩展为tracker cluster来服务，cluster里每个tracker之间是完全对等的，所有的tracker都接受stroage的心跳信息，生成元数据信息来提 供读写服务。同步机制1.文件同步只在同组内的storage server之间进行，采用push方式，即源服务器

4、同步给目标服务器2.一组内storage server之间是对等的。文件上传等操作可以在任一台storage上进行3.源头数据才需要同步，备份数据部需要再次同步Upload file（上传文件的过程）FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete等，以客户端库的方式提供给用户使用。选择tracker server（跟踪服务器）当集群中不止一个tracker server时，由于tracker之间是完全对等的关系，客户端在upload文件时可以任意选择一个trakcer。选择存储的group（存储服务器的卷）当tracker接收到upl

5、oad file的请求时，会为该文件分配一个可以存储该文件的group，支持如下选择group的规则： 1. Round robin，所有的group间轮询 2. Specified group，指定某一个确定的group 3. 3. Load balance，剩余存储空间多多group优先选择storage server（卷下的storage)当选定group后，tracker会在group内选择一个storage server给客户端，支持如下选择storage的规则：1. Round robin，在group内的所有storage间轮询 2. First server ordered b

6、y ip，按ip排序 3. First server ordered by priority，按优先级排序（优先级在storage上配置）选择storage path当分配好storage server后，客户端将向storage发送写文件请求，storage将会为文件分配一个数据存储目录，支持如下规则： 1. Round robin，多个存储目录间轮询 2. 剩余存储空间最多的优先生成Fileid选定存储目录之后，storage会为文件生一个Fileid，由storage server ip、文件创建时间、文件大小、文件crc32和一个随机数拼接而成，然后将这个二进制串进行base64编码，

7、转换为可打印的字符串。选择两级目录当选定存储目录之后，storage会为文件分配一个fileid，每个存储目录下有两级256*256的子目录，storage会按文件fileid进行两次hash（猜测），路由到其中一个子目录，然后将文件以fileid为文件名存储到该子目录下。生成文件名当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名，文件名由group、存储目录、两级子目录、fileid、文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成。文件同步写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage serve

8、r写完文件后，会由后台线程将文件同步至同group内其他的storage server。每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证 集群内所有server的时钟保持同步。storage的同步进度会作为元数据的一部分汇报到tracker上，tracke在选择读storage的时候会以同步进度作为参考。Download file（下载文件的过程）客户端upload f

9、ile成功后，会拿到一个storage生成的文件名，接下来客户端根据这个文件名即可访问到该文件。跟upload file一样，在download file时客户端可以选择任意tracker server。tracker（跟踪服务器）发送download请求给某个tracker，必须带上文件名信息，tracke从文件名中解析出文件的group、大小、创建时间等信息，然后为该请求选择一个storage用来服务读请求。由于group内的文件同步时在后台异步进行的，所以有可能出现在读到时候，文件还没有同步到某些storage server上，为了尽量避免访问到这样的storage，tracker按照如

10、下规则选择group内可读的storage。1. 该文件上传到的源头storage - 源头storage只要存活着，肯定包含这个文件，源头的地址被编码在文件名中。 2. 文件创建时间戳=storage被同步到的时间戳 且(当前时间-文件创建时间戳) 文件同步最大时间（如5分钟) - 文件创建后，认为经过最大同步时间后，肯定已经同步到其他storage了。3. 文件创建时间戳 同步延迟阀值（如一天）。 - 经过同步延迟阈值时间，认为文件肯定已经同步了。小文件合并存储将小文件合并存储主要解决如下几个问题：1. 本地文件系统inode数量有限，从而存储的小文件数量也就受到限制。2. 多级目录+目录

11、里很多文件，导致访问文件的开销很大（可能导致很多次IO）3. 按小文件存储，备份与恢复的效率低FastDFS在V3.0版本里引入小文件合并存储的机制，可将多个小文件存储到一个大的文件（trunk file），为了支持这个机制，FastDFS生成的文件fileid需要额外增加16个字节每个trunk file由一个id唯一标识，trunk file由group内的trunk server负责创建（trunk server是tracker选出来的），并同步到group内其他的storage，文件存储合并存储到trunk file后，根据其offset（类似指针移动长度）就能从trunk file读

12、取到文件。文件在trunk file内的offset编码到文件名，决定了其在trunk file内的位置是不能更改的，也就不能通过compact的方式回收trunk file内删除文件的空间。但当trunk file内有文件删除时，其删除的空间是可以被复用的，比如一个100KB的文件被删除，接下来存储一个99KB的文件就可以直接复用这片删除的存储空 间。HTTP访问支持FastDFS的tracker和storage都内置了http协议的支持，客户端可以通过http协议来下载文件，tracker在接收到请求时，通过http的redirect机制将请求重定向至文件所在的storage上；除了内置的

13、http协议外，FastDFS还提供了通过apache或nginx扩展模块下载文件的支持。其他特性FastDFS提供了设置/获取文件扩展属性的接口（setmeta/getmeta)，扩展属性以key-value对的方式存储在storage上的 同名文件（拥有特殊的前缀或后缀），比如/group/M00/00/01/some_file为原始文件，则该文件的扩展属性存储在/group /M00/00/01/.some_file.meta文件（真实情况不一定是这样，但机制类似），这样根据文件名就能定位到存储扩展属性的文件。以上两个接口作者不建议使用，额外的meta文件会进一步“放大”海量小文件存储问

14、题，同时由于meta非常小，其存储空间利用率也不高，比如100bytes的meta文件也需要占用4K（block_size）的存储空间。FastDFS还提供appender file的支持，通过upload_appender_file接口存储，appender file允许在创建后，对该文件进行append操作。实际上，appender file与普通文件的存储方式是相同的，不同的是，appender file不能被合并存储到trunk file。 FastDFS 用两个AVL 平衡二叉树管理blocks：一个用于管理空闲blocks（V3.05 后采用AVL 管理），一个用于检查block

15、是否存在区域重叠，防止意外情况发生。（防止文件冲突）和memcached这些分布式系统不同。Fastdfs的分布式算法是在服务端实现，HappyFish也在不断改良着算法。最新的是avl树。不过貌似有整rbtree的趋势。从HappyFish那里了解到最新消息，FastDFS最新版本已经支持了Nginx和Apache扩展，对于文件下载通过Ngingx或Apache支持，性能会有很大的提升，Fish强烈推荐使用Nginx或Apahce扩展。FastDFS目前尚存在如下问题（欢迎探讨）。数据安全性1.写一份即成功：从源storage写完文件至同步到组内其他storage的时间窗口内，一旦源stor

16、age出现故障，就可能导致用户数据丢失，而数据的丢失对存储系统来说通常是不可接受的。2.缺乏自动化恢复机制：当storage的某块磁盘故障时，只能换存磁盘，然后手动恢复数据；由于按机器备份，似乎也不可能有自动化恢复机制，除非有预先准备好的热备磁盘，缺乏自动化恢复机制会增加系统运维工作。3.数据恢复效率低：恢复数据时，只能从group内其他的storage读取，同时由于小文件的访问效率本身较低，按文件恢复的效率也会很低，低的恢复效率也就意味着数据处于不安全状态的时间更长。4.缺乏多机房容灾支持：目前要做多机房容灾，只能额外做工具来将数据同步到备份的集群，无自动化机制。存储空间利用率1.单机存储的

17、文件数受限于inode（节点）数量2.每个文件对应一个storage本地文件系统的文件，平均每个文件会存在block_size/2的存储空间浪费。3.文件合并存储能有效解决上述两个问题，但由于合并存储没有空间回收机制，删除文件的空间不保证一定能复用，也存在空间浪费的问题负载均衡1.group机制本身可用来做负载均衡，但这只是一种静态的负载均衡机制，需要预先知道应用的访问特性；同时group机制也导致不可能在group之间迁移数据来做动态负载均衡。相对于MogileFS，FastDFS具有如下特点和优势：fastDFS的函数upload:上传普通文件，包括主文件upload_appender:上

18、传appender文件upload_slave:上传从文件download：下载文件delete:删除文件append:在已有文件后面追加内容set_metadata:设置文件附加属性get_metadata:获取文件附加属性FastDFS服务器端运行时目录结构如下：$base_path |_data：存放数据文件 |_logs：存放日志文件其中，$base_path由配置文件中的参数“base_path”设定。2.2.1 tracker server结构tracker server目录及文件结构：$base_path |_data | |_storage_groups.dat：存储分组信息

19、| |_storage_servers.dat：存储服务器列表 |_logs |_trackerd.log：tracker server日志文件数据文件storage_groups.dat和storage_servers.dat中的记录之间以换行符（n）分隔，字段之间以西文逗号（,）分隔。storage_groups.dat中的字段依次为：(1) group_name：组名(2) storage_port：storage server端口号storage_servers.dat中记录storage server相关信息，字段依次为：(1) group_name：所属组名(2) ip_addr：

20、ip地址(3) status：状态(4) sync_src_ip_addr：向该storage server同步已有数据文件的源服务器(5) sync_until_timestamp：同步已有数据文件的截至时间（UNIX时间戳）(6) stat.total_upload_count：上传文件次数(7) stat.success_upload_count：成功上传文件次数(8) stat.total_set_meta_count：更改meta data次数(9) stat.success_set_meta_count：成功更改meta data次数(10) stat.total_delete_c

21、ount：删除文件次数(11) stat.success_delete_count：成功删除文件次数(12) stat.total_download_count：下载文件次数(13) stat.success_download_count：成功下载文件次数(14) stat.total_get_meta_count：获取meta data次数(15) stat.success_get_meta_count：成功获取meta data次数(16) stat.last_source_update：最近一次源头更新时间（更新操作来自客户端）(17) stat.last_sync_update：最近一

22、次同步更新时间（更新操作来自其他storage server的同步）2.2.2 storage server 结构storage server目录及文件结构：$base_path |_data | |_.data_init_flag：当前storage server初始化信息 | |_storage_stat.dat：当前storage server统计信息 | |_sync：存放数据同步相关文件 | | |_binlog.index：当前的binlog（更新操作日志）文件索引号 | | |_binlog.#：存放更新操作记录（日志） | | |_$ip_addr_$port.mark：存放向

23、目标服务器同步的完成情况 | | | |_一级目录：256个存放数据文件的目录，目录名为十六进制字符，如：00, 1F | |_二级目录：256个存放数据文件的目录，目录名为十六进制字符，如：0A, CF |_logs |_storaged.log：storage server日志文件.data_init_flag文件格式为ini配置文件方式，各个参数如下：# storage_join_time：本storage server创建时间；# sync_old_done：本storage server是否已完成同步的标志（源服务器向本服务器同步已有数据）；# sync_src_server：向本服

24、务器同步已有数据的源服务器IP地址，没有则为空；# sync_until_timestamp：同步已有数据文件截至时间（UNIX时间戳）；storage_stat.dat文件格式为ini配置文件方式，各个参数如下：# total_upload_count：上传文件次数# success_upload_count：成功上传文件次数# total_set_meta_count：更改meta data次数# success_set_meta_count：成功更改meta data次数# total_delete_count：删除文件次数# success_delete_count：成功删除文件次数# total_download_count：下载文件次数# success_download_count：成功下载文件次数# total_get_meta_count：获取meta data次数# success_get_meta_count：成功获取meta data次数# last_source_update：最近一次源头更新时间（更新操作来自客户端）#last_sync_update：最近一次同步更新时间（更新操作来自其他storage server）bi