FastDFS原理和过程

      FastDFS是一个C语言实现的开业轻量级分布式文件系统（作者余庆(happyfish100），支持 Linux、FreeBSD、AID 等 Unix 系统，解决了大数据存储和读写的负载均衡问题，适合存储4k-500MB之间的文件。

 FastDFS架构

      FastDFS服务有三个角色：跟踪服务器（tracker Server）、存储服务（storage Server）、客户端（client）

      tracker server:跟踪服务器主要是做调度工作，起到负载均衡的左右，负责管理所以的storage server 和group ，每个storage在启动后会链接Tracker，告知自己所属的group等信息，并保持周期性心跳，Tracker根据storage心跳信息，建立group---》[storage server list]的映射表，tracker管理的元数据很少，回之间存放在内存，tracker上的元信息都会由storage回报的信息生成的，本身不需要持久化任何数据，tracker之间是对等关系，因此扩展tracker服务非常容易增加tracker服务器即可，所以的tracker都接受storage心跳信息，生成元数据信息来提供读写服务

       storage server：存储服务器，主要提供容量和备份服务，以group为单位，每个group内可以包含多台storage server，数据互为备份，存储容量空间以group内容最小的storage为准，建议group内的storage server配置相同，已group为单位组织存储能够方便的进行应用隔离，负载均衡和副本数定制； 缺点是group的容量容易受单机存储容量的限制，同时group内机器坏掉，数据恢复只能依赖group内其他机器重新同步（坏盘替换，重新挂载重新fdfs_storage即可）

        多个group之间的存储方式有三张策略：round robin（轮询），load balance（选择最大剩余空间组上传文件）、specify froup（知道group上传）

        group中storage存储依赖本地文件系统，storage可以配置多个数据存储目录，磁盘不做raid，直接分别挂载到多个目录，将这些目录配置为storage的数据目录即可

        storage接受写请求时，会根据配置好的规则，选择其中一个存储目录来存储文件；为了避免单个目录下的文件过多，storage第一次启动是，会在每个数据存储目录里创建2机子目录，每级256个，总共65536个，新写的文件会以hash的方式被路由到其中某个子目录下，然后将文件数据直接作为一个本地存储到该目录中

FastDfs工作流程

上传

 

     FastDfs提供基本的文件访问接口，如upload，download，append，delete等

选择tracker server

        集群中tracker之间是对等关系，客户端在上传文件是可用任意选择一个tracker

选择存储group

       当tracker接收到upload file的请求时，会为该文件分配一个可以存储文件的group，目前支持选择group的规则为：

1、Round robin，所以server轮询使用（默认）。2、Specified group，指定某个确定的group。3、Load balance，剩余存储空间较多的group优先。

选择storage server

    当选定group后，tracker会根据group内选择一个storage server给客户端，目前支持选择server规则为：

1、Round robin，所有server轮询使用（默认）。2、根据IP地址进行选择排序选择第一个服务器（IP地址最小者）。3、根据优先级进行排序（上传优先级由storage来设置，参数为upload_priority）

选择storage path（磁盘或者挂载点）

    当分配好了storage server后，客户端将向storage发送写文件请求，storage会根据文件分配一个数据存储目录，目录支持选择存储路径的规则为：

1、Round robin，轮询（默认）。2、load balance，选择使用剩余空间最大的存储路径

选择下载服务器

    目前支持的规则为：

1、轮询方式，可以下载当前文集的任意一storage server。2、从源storage server下载

生成file_id

    选择存储目录后，storage会生成一个file_id，采用Base64编码，包含字段包括storage server ip、文集创建时间、文集大小、文集CRC32交易吗和随机数；每个存储目录下有连个256*256个子目录，storage会安装文集file_id进行两次hash，路由到其中一个子目录，然后将文件以file_id为文件名存储到该目录下，最后生成文件路径:group名称、虚拟磁盘路径，数据两级目录、file_id

其中：

      组名：文件上传后所在的存储组的名称，在文件上传成功后有存储服务器返回，需要客户端自行保存。

     虚拟磁盘路径：存储服务器配置的虚拟路径，与磁盘选择store_path*参数对应

     数据两级目录：存储服务器在每个虚拟磁盘路径下创建的二级目录，用于存储数据文件

同步机制

1. 新增tracker服务器数据同步问题
    由于 storage server 上配置了所有的 tracker server. storage server 和 trackerserver 之间的通信是由 storage server 主动发起的,storage server 为每个 tracker server 启动一个线程进行通信;在通信过程中,若发现该 tracker server 返回的本组 storage server列表比本机记录少,就会将该tracker server上没有的storage server 同步给该 tracker,这样的机制使得 tracker 之间是对等关系,数据保持一致
2. 新增storage服务器数据同步问题
    若新增storage server或者其状态发生变化,tracker server都会将storage server列表同步给该组内所有 storage server;以新增 storage server 为例,因为新加入的 storage server 会主动连接 tracker server,tracker server 发现有新的 storage server 加入,就会将该组内所有的 storage server 返回给新加入的 storage server,并重新将该组的storage server列表返回给该组内的其他storage server;
3. 组内storage数据同步问题
    组内storage server之间是对等的,文件上传、删除等操作可以在组内任意一台storageserver 上进行。文件同步只能在同组内的 storage server 之间进行,采用 push 方式, 即源服务器同步到目标服务器
A. 只在同组内的storage server之间进行同步
B. 源数据才需要同步,备份数据不再同步
C. 特例:新增storage server时,由其中一台将已有所有数据(包括源数据和备份数据)同步到新增服务器

storage server 的七中状态

     通过命令 fdfs_monito /etc/fdfs.client.conf 可以查看ip_addr选项显示storage server当前状态

INIT：初始化，尚未得到同步已有数据的源服务器

WAIT_SYNC：等待同步，已得到同步已有数据的源数据

SYNCING：同步中

DELETE：已删除，该服务器从本组中摘要

OFFLINE：离线

ONLINE：在线，尚不能提供服务

ACTIVE：在线，可以提供服务

组内增加storage serverA状态变化过程:
1. storage server A 主动连接 tracker server,此时 tracker server 将 storageserverA 状态设置为 INIT
2. storage server A 向 tracker server 询问追加同步的源服务器和追加同步截止时间点(当前时间),若组内只有storage server A或者上传文件数为0,则告诉新机器不需要数据同步,storage server A 状态设置为 ONLINE ;若组内没有 active 状态机器,就返回错误给新机器,新机器睡眠尝试;否则 tracker 将其状态设置为 WAIT_SYNC
3. 假如分配了 storage server B 为同步源服务器和截至时间点,那么 storage server B会将截至时间点之前的所有数据同步给storage server A,并请求tracker设置 storage server A 状态为SYNCING;到了截至时间点后,storage server B向storage server A 的同步将由追加同步切换为正常 binlog 增量同步,当取不到更多的 binlog 时,请求tracker将storage server A设置为OFFLINE状态,此时源同步完成
4. storage server B 向 storage server A 同步完所有数据,暂时没有数据要同步时, storage server B请求tracker server将storage server A的状态设置为ONLINE
5. 当 storage server A 向 tracker server 发起心跳时,tracker sercer 将其状态更改为 ACTIVE,之后就是增量同步(binlog)

 

下载

  client 发送下载请求给某个 tracker,必须带上文件名信息,tracker 从文件名中解析出文件的 group、大小、创建时间等信息,然后为该请求选择一个 storage 用于读请求;由于 group 内的文件同步在后台是异步进行的,可能出现文件没有同步到其他storage server上或者延迟的问题, 后面我们在使用 nginx_fastdfs_module 模块可以很好解决这一问题

文件合并原理

小文件合并存储主要解决的问题:
1. 本地文件系统inode数量有限,存储小文件的数量受到限制
2. 多级目录+目录里很多文件,导致访问文件的开销很大(可能导致很多次IO)
3. 按小文件存储,备份和恢复效率低 

 

     FastDFS 提供合并存储功能,默认创建的大文件为 64MB,然后在该大文件中存储很多小文件; 大文件中容纳一个小文件的空间称作一个 Slot,规定 Slot 最小值为 256 字节,最大为 16MB,即小于 256 字节的文件也要占用 256 字节,超过 16MB 的文件独立存储;
    为了支持文件合并机制,FastDFS生成的文件file_id需要额外增加16个字节;每个trunk file 由一个id唯一标识,trunk file由group内的trunk server负责创建(trunk server是tracker 选出来的),并同步到group内其他的storage,文件存储合并存储到trunk file后,根据其文件偏移量就能从trunk file中读取文件