FastDFS分布式文件系统

fastdfs概述

　　FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。
　　FastDFS为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。
　　来源于百度百科，描述的很明确。

fastdfs文件系统架构图

从图中我们可以看出fastdfs文件系统由tracker集群、storage server服务组成。

  • tracker server：是FastDFS文件系统的协调者，负责管理所有的storage server和group，每个storage在启动后会连接tracker，告知自己所属的group等信息，并保持周期性的心跳，tracker根据storage的心跳信息，建立group与storage server 的映射表。文件的上传和删除，并不需要tracker作为中间者，调用storage server操作文件，客户端可以直接操作storage server。
  • storage server：简称storage，以组（卷，group或volume）为单位，一个group内包含多台storage机器，数据互为备份，存储空间以group内容量最小的storage为准，所以建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。

PS：一个group组中的所有storage节点的数据都是相同的。

FastDFS工作原理

　　FastDFS的工作原理，以下面时序图为例子：

在程序上传文件阶段，主要经历的三个过程如下：

  1. 客户端client 调用fastdfs的api,获取可用的tracker server
  2. 调用tracker server 获取可用的组，tracker server 通过负载均衡返回一个最优的storage server
  3. 客户端与storage server建立链接，然后对文件进行上传、删除和追加的操作。

tracker介绍

 　　tracker server是FastDFS文件系统的协调者,其主要作用是负载均衡和调度。tracker在内存中记录分组和storage的状态等信息，不记录文件索引信息，占用的内存量很少。另外，客户端（应用）和storage访问tracker时，tracker扫描内存中的分组和storage信息，然后给出应答。由此可以看出tracker非常轻量化，不会成为系统瓶颈。

　　FastDFS集群中的tracker可以有多台，tracker和storage均不存在单点问题。tracker之间是对等关系，组内的storage之间也是对等关系。传统的Master-Slave结构中的Master是单点，写操作仅针对Master。如果Master失效，需要将Slave提升为Master，实现逻辑会比较复杂。和Master-Slave结构相比，对等结构中所有结点的地位是相同的，每个结点都是Master，不存在单点问题。

 　　从文件系统架构图中可以看出，tracker之间相互独立，不存在直接联系。每次客户端client不管是上传、下载还是删除，首先都要请求tracker，tracker通过负载均衡返回指定组类的最优的storage，然后后client再调用storage进行上传、下载和删除功能。

 　　在fastdfs系统中，客户端clinet和Storage主动连接tracker。storage主动向tracker报告其状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。storage会连接整个集群中所有的tracker，向他们报告自己的状态。storage启动一个单独的线程来完成对一台tracker的连接和定时报告。需要特别说明的是，一个组包含的storage不是通过配置文件设定的，而是通过tracker server获取到的。

storage介绍

　　跟踪器（tracker）主要做调度工作，就像公交车站里面的调务员一样，它负责通过负载均衡选出最优的存储节点（storage）。存储节点（storage）顾名思义就是负责存储、数据同步、数据的操作的一个服务。

　　Storage server（简称storage）以组group为单位，一个group内包含多台storage机器，数据互为备份，存储空间以group内容量最小的storage为准，建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。以group为单位组织存储能方便的进行应用隔离、负载均衡、副本数定制（group内storage server数量即为该group的副本数），比如将不同应用数据存到不同的group就能隔离应用数据，比如group1为内网访问数据，group2为外网访问数据。同时还可根据应用的访问情况来将应用分配到不同的group来做负载均衡；缺点是group的容量受单机存储容量的限制比如gourp1中有3个storage，storage1为100G、storage2为120G、storage为110G，那么对于group1来说存储空间大小就是100G。当group中有机器坏掉时，数据的恢复只能依赖group中的其他机器，所以恢复时间会特别的长。

　　在group中每个storage的存储依赖于本地文件系统，所以storage可以动态增加存储空间大小，比如fastdfs系统使用一段时间之后group1的空间使用完了，那我们可以动态为group1下面的所有storage主机挂载更多的磁盘。而且可以指定那些盘为storage的存储目录比如有5块磁盘，分别挂载在/data/disk1-/data/disk5，那么可将这5个存储目录都配置为storage的数据存储目录。

　　当storage接受到客户端或其它storage同步的写文件请求时，将会根据配置好的规则，选择其中一个存储目录来存储文件。

　　为了防止单个目录下的文件数太多，在storage第一次启动时，会在每个数据存储目录里创建2级子目录，每级256个，总共65536个文件，新写的文件会以hash的方式被路由到其中某个子目录下，然后将文件数据直接作为一个本地文件存储到该目录中。

storage的同步策略

　　文件同步是由独立的线程负责的，每个Storage都有到同组中其他Storage的同步线程，如一组三个Storage，那么每个Storage都有两个线程负责到其他两个Storage的同步。同步线程由Tracker通讯线程启动，因为只有Tracker才知道一组中有哪些Storage。

　　同步线程的执行过程主要由源同步与Binlog同步两部分组成，将在后面小结叙述。 

文件的上传、下载、删除交互过程

　交互过程和FastDFS的工作原理有关，那么这里引用上面的FastDFS的工作原理的时序图进行说明

在程序上传文件阶段，主要经历的三个过程如下：

  1. 客户端client 调用fastdfs的api,获取可用的tracker server
  2. 调用tracker server 获取可用的组，tracker server 通过负载均衡返回一个最优的storage server
  3. 客户端与storage server建立链接，然后对文件进行上传、删除和追加的操作。

上传文件交互过程

　　经过上面三个阶段后，客户端就可以向stroage服务器上传文件了，上传成功后，storage将会返回一个字符串数组，其中results[0]:卷名即组，results[1]:文件名（包含在文件系统的目录结构）。在FastDFS中的文件标识分为两个部分：卷名和文件名，二者缺一不可。

# 组group如group1,文件名由group、存储目录、两级子目录、fileid、文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成。
/group2/M00/00/01/goQeAFUjqu2AdlUPABHKPTiTXBY295.jpg

# 具体的访问地址需自己在代码中拼上域名和端口号
http://xxx.xxx.com:8002/group2/M00/00/01/goQeAFUjqu2AdlUPABHKPTiTXBY295.jpg

文件上传类型有3种：

  1. upload：上传普通文件，包括主文件 ；
  2. upload_appender：上传appender文件，后续可以对其进行append操作【又用作断点续传】 ；
  3. upload_slave：上传从文件；

下载文件交互过程

　　时序图如下：

根据上面时序图，我们可以知道主要分为三部：

  1. 客户端询问tracker下载文件的storage，参数为文件标识（卷名和文件名）；
  2. tracker返回一台可用的storage；
  3. client直接和storage通讯完成文件下载；

文件删除交互过程

 　时序图如下:

从上图中我们可以看出整个交互过程分为3步:

  1. client询问tracker下载文件的storage，参数为文件标识（卷名和文件名）；
  2. tracker返回一台可用的storage；
  3. client直接和storage通讯完成文件删除；

PS：删除成功后，返回int类型的结果值0:文件删除成功，2：文件不存在 ，其它：文件删除出错；

文件同步机制

　　从fastdfs文件系统结构中我们可以看出不管是上传文件、删除文件、修改文件及新增storager，文件的同步都是同组内多台storager之间进行的。下面我们看fastdfs文件系统开发者是怎么描述同步机制的。

　　tracker的配置文件中没有storage，而storage的配置文件中会列举出所有的tracker。这就决定了storage和tracker之间的连接由storage主动发起，storage为每个tracker启动一个线程进行连接和通讯。

　　tracker会在内存中保存storage分组及各个组下的storage，并将连接过自己的storage及其分组保存到文件中，以便下次重启服务时能直接从本地磁盘中获得storage相关信息。storage会在内存中记录本组的所有服务器，并将服务器信息记录到文件中。tracker和storage之间相互同步storage列表。

　　如果一个组内增加了新的storage或者storage的状态发生了改变，tracker都会将storage列表同步给该组内的所有storage。以新增storage为例，因为新加入的storage主动连接tracker，tracker 发现有新的storage server加入，就会将该组内所有的storage server返回给新加入的storage server，并重新将该组的storage

 server列表返回给该组内的其他storage server；

  2. 如果新增加一台tracker server，storage server连接该tracker server，发现该tracker server返回的本组storage server

列表比本机记录的要少，就会将该tracker server上没有的storage server同步给该tracker server。

 

同一组内的storage server之间是对等的，文件上传、删除等操作可以在任意一台storage server上进行。文件同步

只在同组内的storage server之间进行，采用push方式，即源服务器同步给目标服务器。以文件上传为例，假设一个组内有3台storage 

server A、B和C，文件F上传到服务器B，由B将文件F同步到其余的两台服务器A和C。我们不妨把文件F上传到服务器B的操作为源头操

作，在服务器B上的F文件为源头数据；文件F被同步到服务器A和C的操作为备份操作，在A和C上的F文件为备份数据。同步规则总结如下：

 

 1. 只在本组内的storage server之间进行同步；

  2. 源头数据才需要同步，备份数据不需要再次同步，否则就构成环路了；

  3. 上述第二条规则有个例外，就是新增加一台storage server时，由已有的一台storage server将已有的所有数据（包括源头数据和

备份数据）同步给该新增服务器；

 

storage server有7个状态，如下：

  # FDFS_STORAGE_STATUS_INIT      :初始化，尚未得到同步已有数据的源服务器

  # FDFS_STORAGE_STATUS_WAIT_SYNC :等待同步，已得到同步已有数据的源服务器

  # FDFS_STORAGE_STATUS_SYNCING   :同步中

  # FDFS_STORAGE_STATUS_DELETED   :已删除，该服务器从本组中摘除（注：本状态的功能尚未实现）

  # FDFS_STORAGE_STATUS_OFFLINE   :离线

  # FDFS_STORAGE_STATUS_ONLINE    :在线，尚不能提供服务

  # FDFS_STORAGE_STATUS_ACTIVE    :在线，可以提供服务

 

当storage server的状态为FDFS_STORAGE_STATUS_ONLINE时，当该storage server向tracker server发起一次heart beat时，

tracker server将其状态更改为FDFS_STORAGE_STATUS_ACTIVE。



组内新增加一台storage server A时，由系统自动完成已有数据同步，处理逻辑如下：

 

  1. storage server A连接tracker server，tracker server将storage server A的状态设置为FDFS_STORAGE_STATUS_INIT。

storage server A询问追加同步的源服务器和追加同步截至时间点，如果该组内只有storage server A或该组内已成功上传的文件数为0，

则没有数据需要同步，storage server A就可以提供在线服务，此时tracker将其状态设置为FDFS_STORAGE_STATUS_ONLINE，否则

tracker server将其状态设置为FDFS_STORAGE_STATUS_WAIT_SYNC，进入第二步的处理；

 

  2. 假设tracker server分配向storage server A同步已有数据的源storage server为B。同组的storage server和tracker server

通讯得知新增了storage server A，将启动同步线程，并向tracker server询问向storage server A追加同步的源服务器和截至时间点。

storage server B将把截至时间点之前的所有数据同步给storage server A；而其余的storage server从截至时间点之后进行正常同步，只

把源头数据同步给storage server A。到了截至时间点之后，storage server B对storage server A的同步将由追加同步切换为正常同步，

只同步源头数据；

  3. storage server B向storage server A同步完所有数据，暂时没有数据要同步时，storage server B请求tracker server将

storage server A的状态设置为FDFS_STORAGE_STATUS_ONLINE；

  4 当storage server A向tracker server发起heart beat时，tracker server将其状态更改为FDFS_STORAGE_STATUS_ACTIVE。

 

从上面的描述，我觉得作者描述的非常的清楚，让我们这些使用者能够非常容易理解。

 

同步时间管理

 

刚刚我们从上面了解了fastdfs文件系统中组内的多个storage server之间同步的机制，那文件同步是什么时候进行呢？是文件上传成功后，

其它的storage server才开始同步，其它的storage server怎么去感知，tracker server是怎么通知storage server呢？

 

管理同步时间

当一个文件上传成功后，客户端马上发起对该文件下载请求（或删除请求）时，tracker是如何选定一个适用的存储服务器呢？

其实每个存储服务器都需要定时将自身的信息上报给tracker，这些信息就包括了本地同步时间（即，同步到的最新文件的时间戳）。

而tracker根据各个存储服务器的上报情况，就能够知道刚刚上传的文件，在该存储组中是否已完成了同步。在storage server中这些信息是

以Binlog文件的形式存在的。

 

Binlog文件

当Storaged server启动时会创建一个 base_path/data/sync 同步目录，该目录中的文件都是和同组内的其它 Storaged server之间的

同步状态文件，如192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.100（binlog.index）；

192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.000 binlog.index

binlog.index 记录当前使用的Binlog文件序号，如为10，则表示使用binlog.010

binlog.100真实地Binlog文件

192.168.1.2_33450.mark 同步状态文件，记录本机到192.168.1.2_33450的同步状态

在Mark文件中内容：由binlog_index和binlog_offset两项组成，以192.168.1.2_33450.mark为例其中binlog_index表示上次同步192.168.

1.2机器的最后一条

binlog文件索引，binlog_offset表示上次同步192.168.1.2机器的最后一条binlog偏移量，如果程序重启了，也只要从这个位置开始向后同步。

Binlog文件内容：在该文件中是以binlog日志组成，比如：

1470292943 c M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg

1470292948 C M00/03/63/QkIPAFdWPUCAfiraAAG93gO_2Ew311.png

1470292954 d M00/03/62/QkIPAFdWOyeAO3eUAABvALuMG64183.jpg

1470292959 C M00/01/23/QUIPAFdVQZ2AL_o-AAAMRBAMk3s679.jpg

1470292964 c M00/03/62/QkIPAFdVOsCAcxeQAAGTdbQsdVs062.jpg

1470292969 c M00/03/62/QkIPAFdVOnKAXu1NAABq9pkfsms63.jpeg

1470293326 D M00/03/62/QkIPAFdVMnGAZYSZAABq9pkfsms33.jpeg

 

其中的每一条记录都是使用空格符分成三个字段，分别为：

第一个字段  表示文件upload时间戳 如：1470292943

第二个字段 表示文件执行操作，值为下面几种

C表示源创建、c表示副本创建

A表示源追加、a表示副本追加

D表示源删除、d表示副本删除

T表示源Truncate、t表示副本Truncate

 其中源表示客户端直接操作的那个Storage即为源，其他的Storage都为副本

第三个字段 表示文件 如M00/03/61/QkIPAFdQCL-AQb_4AAIAi4iqLzk223.jpg

 

Storage server具体同步过程

 

从fastdfs文件同步原理中我们知道Storaged server之间的同步都是由一个独立线程负责的，这个线程中的所有操作都是以同步方式

执行的。比如一组服务器有A、B、C三台机器，那么在每台机器上都有两个线程负责同步，如A机器，线程1负责同步数据到B，线程2负责同

步数据到C。每个同步线程负责到一台Storage的同步，以阻塞方式进行。

以IP为192.168.1.1的Storaged severe的服务器为例，它的同步目录下有192.168.1.2_33450.mark 192.168.1.3_33450.mark binlog.100

等文件现在Storaged severe将会从ip为192.168.1.2的Storaged severe的存储里面同步数据。

 

1）打开对应Storage server的mark文件，如负责到192.168.1.1的同步则打开192.168.1.2_33450.mark 文件，从中读取binlog_index、

binlog_offset两个字段值，如取到值为：100、1000，那么就打开binlog.100文件，seek到1000这个位置。

2）进入一个while循环，尝试着读取一行，若读取不到则睡眠等待。若读取到一行，并且该行的操作方式为源操作，如C、A、D、T

（大写的都是），则将该行指定的操作同步给对方（非源操作不需要同步），同步成功后更新binlog_offset标志，该值会定期写入到192.168.1

.2_33450.mark文件之中。

同步过程中可能因为同步较为缓慢，导致可能在同步一个文件之前，文件已经被客户端删除，此时同步线程将打印一条日志，然后直接处理后

面的Binlog。

 

posted @ 2018-03-23 11:54  SpeicalLife  阅读(905)  评论(0)  编辑  收藏  举报