分布式文件系统FastDFS

一、概述

FastDFS是一个用c语言编写的开源的轻量级分布式文件系统，是我国一款开源的分布式文件系统 由阿里巴巴开发，其主要架构由跟踪服务器（tracker server）、存储服务器（storage server）和客户端（client）三个部分组成，主要解决了海量数据存储问题，为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。特别适合以中小文件（建议范围：4KB < file_size <500MB）为载体的在线服务，如相册网站、视频网站等；注意，如果需要对外提供http服务需要在storage server上安装nginx+fastdfs_module服务。Fastdfs在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10，提升并发IO的性能、简单负载均衡及数据的冗余备份；同时通过线性的添加新的逻辑存储组，从容实现存储容量的线性扩容。适合应用于：单集群部署的应用、存储后基本不做改动、小中型文件场景。

文件下载上，除了支持通过API方式，目前还提供了apache和nginx的插件支持，同时也可以不使用对应的插件，直接以Web静态资源方式对外提供下载。安装官方介绍，FastDFS系统存储容量已经达到900T，物理机器已经达到100台（50个组）。

Fastdfs支持Linux、FreeBSD等UNIX系统类google FS，不是通用的文件系统**，只能通过专有API访问**，目前提供了C、Java和PHP API为互联网应用量身定做，解决大容量文件存储问题，追求高性能和高扩展性FastDFS可以看做是基于文件的key value pair存储系统，称作分布式文件存储服务更为合适。目前FastDFS GitHub上已明确支持Anolis 8和7，因此相关OS改造时可选用Anolis系列。

特点：

1>FastDFS是一个轻量级的开源分布式文件系统
2>FastDFS主要解决了大容量的文件存储和高并发访问的问题，文件存取时实现了负载均衡，大（上传存在断点问题）、中、小文件均可以很好支持，可以存储海量小文件（V3.x加入）；另针对小文件存储问题，FastDFS 提供了文件合并解决方案。FastDFS 默认创建大文件为 64M，大文件可以存储很多小文件，容纳一个小文件的空间叫slot，solt 最小256字节，最大16M。小于256字节当256字节存储，超过16M文件单独存储。默认未开启合并 ，FastDFS生成的file_id 和磁盘上实际存储的文件一一对应；
3>FastDFS实现了软件方式的RAID，可以使用廉价的IDE硬盘进行存储,增强系统的并发处理能力及数据容错恢复能力
4>支持存储服务器在线扩容，一台 storage 支持多块磁盘，支持单盘数据恢复；
5>支持相同内容的文件只保存一份，节约磁盘空间
6>FastDFS特别适合大中型网站使用，用来存储资源文件（如：图片、文档、音频、视频等等）
7>每次上传文件后都会返回一个地址，用户需要自己保存此地址
8>为了支持大容量，存储节点（服务器）采用了分卷（或分组）的组织方式。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。存储服务器上可以保存文件附加属性。
9>Tracker服务器是整个系统的核心枢纽，其完成了访问调度（负载均衡），监控管理Storage服务器，由此可见Tracker的作用至关重要，也就增加了系统的单点故障，为此FastDFS支持多个备用的Tracker，虽然实际测试发现备用Tracker运行不是非常完美，但还是能保证系统可用。分组存储，简单灵活；对等结构，不存在单点；
10>在文件同步上，只有同组的Storage才做同步，由文件所在的源Storage服务器push至其它Storage服务器，目前同步是采用Binlog方式实现，由于目前底层对同步后的文件不做正确性校验，因此这种同步方式仅适用单个集群点的局部内部网络，如果在公网上使用，肯定会出现损坏文件的情况，需要自行添加文件校验机制。
11>支持主从文件，非常适合存在关联关系的图片，在存储方式上，FastDFS在主从文件ID上做取巧，完成了关联关系的存储。文件 ID 由 FastDFS 生成，作为文件访问凭证。FastDFS 不需要传统的 name server 或 meta server；
12>不支持断点续传，对大文件将是噩梦（FastDFS不适合大文件存储）,目前v5.x版本已支持断点续传，采用分块追加的方式上传；另外支持多线程方式上传和下载文件；
13>对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略
13>通过API下载，存在单点的性能瓶颈
14>HTTP支持：FastDFS的tracker和storage都内置了http协议的支持，客户端可以通过http协议来下载文件，tracker在接收到请求时，通 过http的redirect机制将请求重定向至文件所在的storage上；除了内置的http协议外，FastDFS还提供了通过apache或nginx扩展模块下载文件的支持。提供了 nginx 扩展模块，可以和 nginx 无缝衔接；
15>

目前分布式文件存储系统的解决方案

TFS、FASTDFS、HDFS都是通过将数据分布到多个存储节点来解决问题

1、通过将多个文件打包存储到大文件（block）以及扁平化的目录结构来解决问题
2、通过block多副本以及按block复制的方式来解决问题。
3、block通常64MB大小，block内部存储的每个文件由一个fileid标识。

相关资源：软件下载地址、GitHub地址、配置文档、参考资料、Java客户端、Nginx支持

二、Fastdfs原理及架构

如上图所示，FastDFS服务有三个角色：跟踪服务器(tracker server)、存储服务器(storage server)和客户端(client)。其中：

1）Storage server（简称storage）以组（卷，group或volume）为单位组织，一个group内包含多台storage机器，数据互为备份，存储空间以group内容量最小的storage为准，所以建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。其主要提供容量和备份服务。注意：文件同步只能在 Group 内的Storage Server之间进行，采用push方式，即源服务器同步给目标服务器。

以group为单位组织存储能方便的进行：应用隔离、负载均衡、副本数定制（group内storage server数量即为该group的副本数），比如：将不同应用数据存到不同的group就能隔离应用数据，同时还可根据应用的访问特性来将应用分配到不同的group来做负载均衡；缺点：是group的容量受单机存储容量的限制，同时当group内有机器坏掉时，数据恢复只能依赖group内地其他机器，使得恢复时间会很长。

group内每个storage的存储依赖于本地文件系统，storage可配置多个数据存储目录，比如有10块磁盘，分别挂载在/data/disk1-/data/disk10，则可将这10个目录都配置为storage的数据存储目录。

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

多个group之间的存储方式有3种策略:round robin(轮询)、load balance(选择最大剩余空 间的组上传文件)、specify group(指定group上传)

**group ：**组， 也可称为卷。 同组内服务器上的文件是完全相同的 ，同一组内的storage server之间是对等的， 文件上传、 删除等操作可以在任意一台storage server上进行 。
**meta data ：**文件相关属性，键值对（ Key Value Pair） 方式，如：width=1024,heigth=768 。

2）Tracker server： Tracker是FastDFS的协调者，负责管理所有的storage server和group，每个storage在启动后会连接Tracker（即需先启动Tracker，再启动Storage），把自己注册到TrackerServer上，并且定期报告自身状态信息，包括：磁盘剩余空间、文件同步状况、文件上传下载次数、自己所属的group等等统计信息，并保持周期性的心跳，tracker根据storage的心跳信息，建立group==>[storage server list]的映射表。负责调度和负载均衡，并不需要存储文件的索引信息，因为文件上传后 stroage 返回给客户端的文件ID中就包含了组名、文件相对路径和文件名等(文件ID还包含了文件大小、时间戳、源storage server IP地址、文件内容校验码、随机数等), client可以根据文件ID直接定位到文件所在的组(但具体哪个storage server下载就需要询问tracker server)。

Tracker需要管理的元信息很少，会全部存储在内存中；另外tracker上的元信息都是由storage汇报的信息生成的，本身不需要持久化任何数据，这样使得tracker非常容易扩展，直接增加tracker机器即可扩展为tracker cluster来服务，cluster里每个tracker之间是完全对等的，所有的tracker都接受stroage的心跳信息，生成元数据信息来提供读写服务。tracker和storage中的服务器均可以随时增加或下线而不会影响线上服务，其中跟踪器中的所有服务器都是对等的，可以根据服务器的压力情况随时增加或减少。

Tracker相当于FastDFS的大脑，不论是上传还是下载都是通过tracker来分配资源；客户端一般可以使用ngnix等静态服务器来调用或者做一部分的缓存；存储服务器内部分为卷[Volume]（或者叫做组[group]），卷于卷之间是平行的关系，可以根据资源的使用情况随时增加，卷内服务器文件相互同步备份，一个组中的存储服务器中的文件都是相同的，组中的多台存储服务器起到了冗余备份和负载均衡的作用，数据互为备份，以达到容灾的目的，存储空间以group内容量最小的storage为准，所以建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。

3) client: Upload file，FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete等，以客户端库的方式提供给用户使用。Client访问StorageServer之前，是先访问TrackerServer，来动态获取StorageServer的连接信息的，最终连接到一个可用的StorageServer进行数据传输。tracker 接收到client上传请求时会先给该文件分配一个可以存储的 Group ，然后在Group中分配一个Storage Server给客户端，最后在接收到客户端写文件请求时，Storage Server 会分配一个数据存储目录并写入。

client连接tracker server，tracker server查询storage server 列表，根据配置的负载均衡算法（随机，第一 storage server，第一storage server 优先级排序（最小值）），返回一个storage ip，client 根据返回的ip连接 storage server 进行上传，storage server 根据配置的存储路径，根据指定的负载算法（随机，最大剩余空间）选择一个路径存储到磁盘上，并返回结果。注：Fastdfs 只提供文件的基本操作，没有对文件重复上传做处理，如果业务上需要实现文件重复上传可使用fastdfs配合fastdht处理，fastdht是一种分布式的kv存储数据库，以Berkeley DB作为数据存储。推荐使用业务逻辑来实现去重，避免引入过多组件。

组内增加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)
6. 整个源同步过程是源机器启动一个同步线程,将数据 push 到新机器,最大达到一个磁盘的 IO,不能并发
7. 由于源同步截止条件是取不到 binlog,系统繁忙,不断有新数据写入的情况,将会导致一直无法完成源同步过程

2.1、FastDFS 工作流程

1>FastDFS上传文件流程图，FastDFS 提供基本的文件访问接口,如 upload、download、append、delete 。

上图中，当client想tracker请求上传文件，当集群中不止一个tracker server时，由于tracker之间是完全对等的关系，客户端在upload文件时可以任意选择一个trakcer。当tracker接收到upload file的请求时，依据group选择规则（Round robin，所有的group间轮询、Specified group，指定某一个确定的group、Load balance，剩余存储空间多多group优先）会为该文件分配一个可以存储该文件的group，当选定group后，tracker会依据storage的规则（Round robin、First server ordered by ip、First server ordered by priority，）在group内选择一个storage server给客户端，当分配好storage server后，客户端将向storage发送写文件请求，storage也会根据(多个存储目录间轮询、剩余存储空间最多的优先)将会为文件分配一个数据存储目录；定存储目录之后，storage会为文件生一个File_id，由storage server ip、文件创建时间、文件大小、文件crc32和一个随机数拼接而成，然后将这个二进制串进行base64编码，转换为可打印的字符串；当选定存储目录之后，storage会为文件分配一个file_id，每个存储目录下有两级256*256的子目录，storage会按文件file_id进行两次hash（猜测），路由到其中一个子目录，然后将文件以file_id为文件名存储到该子目录下；当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名，文件名由: group、存储目录、两级子目录、file_id、文件后缀名（由客户端指定，主要用于区分文件类型）拼接而成，最后返回文件路径给客户端。生成文件的格式如下：

group1
文件上传到了存储节点的哪一个组
如果有多个组这个组名可变的

M00 - 虚拟目录，和存储节点的配置项有映射，M00对应store_path0，M01对应store_path1; 其中，Mxx中的xx为十六进制字符，表示存放的基路径（base path）序号。如果存放的base path只有一个，且store_path0也只有一个，那固定就是M00，如果再加一个store_path1，就变成M01，以此类推；另外，Storaged server启动时会创建一个 base_path/data/sync 同步目录，该目录中的文件都是和同组内的其它 Storaged server之间的同步信息，新加入的storage会产生mark文件，数据同步的动作（增加，删除）依据binlog.000中的记录，其中binlog.000 是真实地Binlog文件，binlog.index # 记录当前使用的Binlog文件序号，如为10，则表示使用binlog.010
store_path0=/home/fastdfs/data -> M00
store_path1=/homefastdfs1/data -> M01

00/00 为实际的文件存储路径，且它是可变的

wKjR_VlrEfOAdIZyAAAJTOwCGr437275.md 文件名包含的信息：
采用Base64编码
包含的字段包括
源storage server Ip 地址
文件创建时间
文件大小
文件CRC32效验码（循环冗余校验）
随机数

wKjR_VlrEfOAdIZyAAAJTOwCGr437275.md
| 4bytes | 4bytes | 8bytes |4bytes | 2bytes |
| ip | timestamp | file_size |crc32 | 校验值 |

2>文件同步

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时,由其中一台将已有所有数据(包括源数据和备份数据)同步到新增服务器。

写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage server写完文件后，会由后台线程将文件同步至同group内其他的storage server。

每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有server的时钟保持同步。

storage的同步进度会作为元数据的一部分汇报到tracker上，tracke在选择读storage的时候会以同步进度作为参考。

比如一个group内有A、B、C三个storage server，A向C同步到进度为T1 (T1以前写的文件都已经同步到B上了），B向C同步到时间戳为T2（T2 > T1)，tracker接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳为T1（即所有T1以前写的数据都已经同步到C上了）；同理，根据上述规则，tracker会为A、B生成一个同步时间戳。

FastDFS 文件同步采用binlog异步复制方式，Storage Server 使用binlog文件记录文件上传、删除等操作，根据Binlog进行文件同步。Binlog中只记录文件ID和操作，不记录文件内容 .binlog 格式如下：

时间戳	操作类型	文件名
1790541373	C	M02/50/C9/CtAqWVjTbm2AIqTkAbACd_nIZ7M727.jpg

1790541373 C M02/50/C9/CtAqWVjTbm2AIqTkAbACd_nIZ7M727.jpg

其中操作类型符号：

C表示源创建、c表示副本创建
A表示源追加、a表示副本追加
D表示源删除、d表示副本删除

3>下载文件流程图,客户端upload file成功后，会拿到一个storage生成的文件名，接下来客户端根据这个文件名即可访问到该文件。

跟upload file一样，在download file时客户端可以选择任意tracker server。

tracker发送download请求给某个tracker，必须带上文件名信息，tracke从文件名中解析出文件的group、大小、创建时间等信息，然后为该请求选择一个storage用来服务读请求。由于group内的文件同步时在后台异步进行的，所以有可能出现在读到时候，文件还没有同步到某些storage server上，为了尽量避免访问到这样的storage，tracker按照如下规则选择group内可读的storage。

该文件上传到的源头storage - 源头storage只要存活着，肯定包含这个文件，源头的地址被编码在文件名中。
文件创建时间戳==storage被同步到的时间戳 且(当前时间-文件创建时间戳) > 文件同步最大时间（如5分钟) - 文件创建后，认为经过最大同步时间后，肯定已经同步到其他storage了。

文件创建时间戳 < storage被同步到的时间戳。 - 同步时间戳之前的文件确定已经同步了
(当前时间-文件创建时间戳) > 同步延迟阀值（如一天）。 - 经过同步延迟阈值时间，认为文件肯定已经同步了。

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中读取文件

同步时间管理：

当一个文件上传成功后，客户端马上发起对该文件下载请求（或删除请求）时，tracker是如何选定一个适用的存储服务器呢？ 其实每个存储服务器都需要定时将自身的信息上报给tracker，这些信息就包括了本地同步时间（即，同步到的最新文件的时间戳）。而tracker根据各个存储服务器的上报情况，就能够知道刚刚上传的文件，在该存储组中是否已完成了同步。同步信息上报如下图：

写文件时，客户端将文件写至group内一个storage server即认为写文件成功，storage server写完文件后，会由后台线程将文件同步至同group内其他的storage server。

每个storage写文件后，同时会写一份binlog，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步，storage会记录向group内其他storage同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有server的时钟保持同步。

storage的同步进度会作为元数据的一部分汇报到tracker上，tracke在选择读storage的时候会以同步进度作为参考。 比如一个group内有A、B、C三个storage server，A向C同步到进度为T1 (T1以前写的文件都已经同步到B上了），B向C同步到时间戳为T2（T2 > T1)，tracker接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳为T1（即所有T1以前写的数据都已经同步到C上了）；同理，根据上述规则，tracker会为A、B生成一个同步时间戳。

精巧的文件ID-FID：

说到下载就不得不提文件索引（又称：FID）的精巧设计了。文件索引结构如下图，是客户端上传文件后存储服务器返回给客户端，用于以后访问该文件的索引信息。文件索引信息包括：组名，虚拟磁盘路径，数据两级目录，文件名。

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

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

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

文件名：与文件上传时不同。是由存储服务器根据特定信息生成，文件名包含：源存储服务器IP地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。

快速定位文件：

知道FastDFS FID的组成后，我们来看看FastDFS是如何通过这个精巧的FID定位到需要访问的文件。

1、通过组名tracker能够很快的定位到客户端需要访问的存储服务器组，并将选择合适的存储服务器提供客户端访问；

2、存储服务器根据“文件存储虚拟磁盘路径”和“数据文件两级目录”可以很快定位到文件所在目录，并根据文件名找到客户端需要访问的文件。

文件合并存储（默认未开启）：多个file_id对应文件被存储成了一个大文件 。trunk文件名格式：/fastdfs/data/00/000001 文件名从1开始递增。而生成的file_id 更长，会新增16个字节额外内容用来保存偏移量等信息。

2.2、FastDFS+Nginx实现文件服务器

三、常见文件系统对比

相关文章地址：https://www.cnblogs.com/yswenli/p/7234579.html

如上图所示为GFS分布式文件系统，GlusterFS是Red Hat旗下的一款开源分布式文件系统，它具备高扩展、高可用及高性能等特性，由于其无元数据服务器的设计，使其真正实现了线性的扩展能力，使存储总容量可 轻松达到PB级别，支持数千客户端并发访问；对跨集群，其强大的Geo-Replication可以实现集群间数据镜像，而且是支持链式复制，这非常适用 于垮集群的应用场景

特性：

1）目前GlusterFS支持FUSE方式挂载，可以通过标准的NFS/SMB/CIFS协议像访问本体文件一样访问文件系统，同时其也支持HTTP/FTP/GlusterFS访问，同时最新版本支持接入Amazon的AWS系统
2）GlusterFS系统通过基于SSH的命令行管理界面，可以远程添加、删除存储节点，也可以监控当前存储节点的使用状态
3）GlusterFS支持集群节点中存储虚拟卷的扩容动态扩容；同时在分布式冗余模式下，具备自愈管理功能，在Geo冗余模式下，文件支持断点续传、异步传输及增量传送等特点。

四、FastDFS部署

FastDFS是C语言开发，建议在linux上运行，安装FastDFS需要先将官网下载的源码进行编译，编译依赖gcc环境，如果没有gcc环境，需要安装gcc：yuminstall gcc-c++；FastDFS依赖libevent库，需要安装：
yum -y install libevent；，还需要libfastcommon，其包含了FastDFS运行所需要的一些基础库。libfastcommon安装好后会自动将库文件拷贝至/usr/lib64下，由于FastDFS程序引用usr/lib目录所以需要将/usr/lib64下的库文件拷贝至/usr/lib下。更多参看官方配置指导。

部署参考架构图：

1）编辑hosts文件配置，保证各主机文件名和IP地址可正确解析

cat >> /etc/hosts << EOF #输入host文件内容

2）安装配置tracker server：

环境依赖准备：yum -y install gcc-c++ libevent

依赖软件名称	说明
libfastcommon	FastDFS分离出的公用函数库
libserverframe	FastDFS分离出的网络框架
fastdfs-nginx-module	FastDFS和nginx的关联模块

安装libfastcommon：

cd /opt
git clone https://github.com/happyfish100/libfastcommon.git
cd libfastcommon/
./make.sh
./make.sh install

安装libserverframe：

#编译安装
git clone https://github.com/happyfish100/libserverframe.git --depth 1
cd libserverframe/
./make.sh && ./make.sh install 

3）安装fastdfs：

cd /opt
git clone https://github.com/happyfish100/fastdfs.git
cd fastdfs
./make.sh
./make.sh install
#新安装方式中，多了如下步骤：
#配置文件准备
cp /usr/local/src/fastdfs/conf/http.conf /etc/fdfs/ #供nginx访问使用
cp /usr/local/src/fastdfs/conf/mime.types /etc/fdfs/ #供nginx访问使用

#YUM方式
rpm -ivh http://www.fastken.com/yumrepo/el8/noarch/FastOSrepo-1.0.0-1.el8.noarch.rpm  #Anolis 8
rpm -ivh http://www.fastken.com/yumrepo/el7/noarch/FastOSrepo-1.0.0-1.el7.centos.noarch.rpm  #Anolis 7
#安装依赖
yum install git gcc gcc-c++ make automake autoconf libtool pcre pcre-devel zlib zlib-devel openssl-devel wget vim -y
#安装 FastDFS软件包
yum install fastdfs-server fastdfs-tool fastdfs-config -y

主要配置文件有：

cracker.conf //负责均衡调度服务器配置文件
client.conf //客户端上传配置文件
http.conf //http服务器配置文件
storage.conf//文件存储服务器配置文件
mime.types //文件类型配置文件
mod_fastdfs.conf //nginx读取fdfs模块配置文件

4）修改tracker server的配置文件

cp /etc/fdfs/tracker.conf.sample /etc/fdfs/tracker.conf
vim /etc/fdfs/tracker.conf  #如下配置
bind_addr= 改为 bind_addr=tracker的地址
#端口
port=22122
#连接超时时间 （s）
connect_timeout=30
network_timeout=60
#存储tracker server 数据和日志的基础路径
base_path=/home/yunwei/fastdfs 改为 base_path=/data/fastdfs
#tracker server 最大连接数
max_connections=256
#处理连接事件线程数
accept_threads=1
#工作线程数
work_threads=8
#最大最小缓冲空间大小
min_buff_size = 8KB
max_buff_size = 256KB

#上传时 存储group负载均衡算法：
#0 随机；1 指定；2  选择最大剩余空间的group
store_lookup=2
# 指定存储组，当 store_lookup=1 时生效
store_group=group2
# 组内storage server 负载算法
#0 随机；1 组内第一个有限；2 组内第一个权重排序
# 备注: 如果 use_trunk_file=true, store_server 必须为 1或2
store_server=0  #建议

# 一个服务器有多个存储路径（多磁盘挂载点）的负载算法
# 0: 随机上传
# 2:  选择最大剩余空间的挂载点 上传 
store_path=0  #建议
#下载文件负载均衡算法
# 0: 随机
# 1: 源文件服务器
download_server=0  #建议
#保留系统或其他应用程序的存储空间
#如果任何group的某个storage server的空闲（可用）空间<＝reserved_storage_space;那么没有文件可以上传到这个组。
#字节单位可以是如下之一：千兆字节 G、兆字节   M 、千字节   K、字节单位 B或者 xx.xx% 如保留值为10.01%
reserved_storage_space = 10%
#日志级别:emerg、alert、crit、error、warn、notice、info\debug
log_level=info

# 访问限制：allow_hosts 属性可出现一次或多次, value 可以是 ip 或 hostname,
# "*"  match all ip addresses
#  如： CIDR ips 192.168.5.64/26
# ip 范围 10.0.1.[0-254] and host[01-08,20-25].domain.com
# allow_hosts=10.0.1.[1-15,20]
# allow_hosts=host[01-08,20-25].domain.com
# allow_hosts=192.168.5.64/26
allow_hosts=*
#从缓冲区刷新日志到磁盘的时间间隔（s）
sync_log_buff_interval = 10
# 检查 storage server 存储的时间间隔（s）
check_active_interval = 120
#（线程 stack 大小）
thread_stack_size = 64KB
#当存储服务器的IP地址改变时自动调整
storage_ip_changed_auto_adjust = true
#storage server 同步文件 最大延时 秒数 默认 86400 一天
storage_sync_file_max_delay = 86400
#同步单个文件耗时最大秒数 默认300s
storage_sync_file_max_time = 300
#是否开启小文件合并存储 trunk存储
use_trunk_file = false 
#trunk文件最小分配单元
slot_min_size = 256
#trunk内部存储的最大文件，超过该值会被独立存储
slot_max_size = 16MB
#trunk文件大小
trunk_file_size = 64MB
#是否预先创建trunk文件
trunk_create_file_advance = false
#预先创建trunk文件的基准时间
trunk_create_file_time_base = 02:00
#预先创建trunk文件的时间间隔
trunk_create_file_interval = 86400
#trunk创建文件的最大空闲空间
trunk_create_file_space_threshold = 20G
#启动时是否检查每个空闲空间列表项已经被使用
trunk_init_check_occupying = false
#是否纯粹从trunk-binlog重建空闲空间列表
trunk_init_reload_from_binlog = false
#对trunk-binlog进行压缩的时间间隔
trunk_compress_binlog_min_interval = 0
#是否使用 storage_ids配置，考虑后期数据迁移，建议true开启 storage_id ，而不使用ip作为storage server 标识，迁移方便
use_storage_id = true
#存储storage_ids配置的文件名称
storage_ids_filename = storage_ids.conf
#文件名中id类型 id|ip 
# ip storage server ip
# id storage server id
id_type_in_filename = id  #建议
#如果存储从文件使用符号链接
store_slave_file_use_link = false
#是否 每天 rotate error log 
rotate_error_log = false
#每天 rotate 时间
error_log_rotate_time=00:00
# rorate log 代销
rotate_error_log_size = 0
#日志保存天数
log_file_keep_days = 0
#是否使用连接池
use_connection_pool = false
#连接池连接空闲时间
connection_pool_max_idle_time = 3600


#tracker server HTTP 端口 5.x版本取消内置http
http.server_port=8080   #改为 http.server_port=80
# 检查 storage HTTP server 存活 间隔 seconds
http.check_alive_interval=30
http.check_alive_type=tcp
http.check_alive_uri=/status.html

5）启动tracker server并加入开机启动

mkdir -p /data/fastdfs
/etc/init.d/fdfs_trackerd start
验证：netstat -tnlp|grep fdfs
/sbin/chkconfig --add fdfs_trackerd
/sbin/chkconfig --level 2345 fdfs_trackerd on

6）安装配置storage server：

yum -y install gcc-c++ libevent

安装libfastcommon

cd /opt
git clone https://github.com/happyfish100/libfastcommon.git
cd libfastcommon/
./make.sh
./make.sh instal

安装fastdfs:

 cd /opt
 git clone https://github.com/happyfish100/fastdfs.git
 cd fastdfs
 ./make.sh
 ./make.sh install

7）配置storage server，更多配置参看fastdfs.md。

cp /etc/fdfs/storage.conf.sample /etc/fdfs/storage.conf

vim /etc/fdfs/storage.conf #修改storage server的配置文件：

bind_addr= 改为 bind_addr=storage的ip
//base_path需要和tracker部分的base_path保持一致，如果有修改过tracker的
base_path=/home/yuqing/fastdfs 改为 base_path=/data/fastdfs
//修改storage的资源存放路径
store_path0=/home/yuqing/fastdfs 改为 store_path0=/data/fastdfs
//如果有多个挂载磁盘则定义多个store_path，如下
//store_path1=......
//store_path2=......
//修改storage的对应的tracker_server的ip地址和端口
tracker_server=tracker地址:22122
//如果有多个则配置多个tracker_server
//tracker_server=......
//tracker_server=......
http.server_port=8888 改为 http.server_port=80

#负载均衡，轮询
store_server=0
store_path=0
download_server=0

# 限制主机访问：allow_hosts 属性可出现一次或多次, value 可以是 ip 或 hostname,
# "*" ：match all ip addresses
#  CIDR ips  如：192.168.5.64/26
# ip 范围 10.0.1.[0-254] and host[01-08,20-25].domain.com
# allow_hosts=10.0.1.[1-15,20]
# allow_hosts=host[01-08,20-25].domain.com
# allow_hosts=192.168.5.64/26
allow_hosts=*



# the mode of the files distributed to the data path文件分发到数据路径
# 0: round robin(default)循环（默认）
# 1: random, distributted by hash code随机，用hash分配
file_distribute_path_mode=0

#当文件分配到file_distribute_path_mode=0 （循环）时，当写入文件计数达到这个数时，然后轮询到下一个路径，默认值为100
file_distribute_rotate_count=100

#当写入大文件到磁盘时，
# 0: never call fsync
# other: call fsync when written bytes >= this bytes
# default value is 0 (never call fsync)
fsync_after_written_bytes=0

# 检查文件是否重复，如果检查文件重复，当设置为true时，使用FASDHT存储文件索引
# 1 or yes: 检查
# 0 or no: 不检查；default value is 0
check_file_duplicate=0

# 文件签名算法 用于检查文件重复 hash
## hash: four 32 bits hash code，default value is hash since V4.01
## md5: MD5 signature
file_signature_method=hash

#其他配置参考
disabled=false
group_name=group1  #如果不配置时，将从tracker server 获取 ,但必须保证tracker.conf 中 use_storage_id=true且 storage_ids.conf 必须正确配置好
bind_addr=172.18.1.22
client_bind=true
port=23000
connect_timeout=90
network_timeout=90
heart_beat_interval=90
stat_report_interval=60
base_path=/opt/fdfsdata/storage
max_connections=256
buff_size = 256KB
accept_threads=1
work_threads=4
disk_rw_separated = true
disk_reader_threads = 1
disk_writer_threads = 1
sync_wait_msec=