微服务轮子项目（35） -FastDFS分布式文件系统

1. 概述

通过独立文件服务器可以解决一些问题，如果某天存储文件的那台服务突然down了怎么办？可能你会说，定时将文件系统备份，这台down机的时候，迅速切换到另一台就OK了，但是这样处理需要人工来干预。另外，当存储的文件超过100T的时候怎么办？单台服务器的性能问题？这个时候我们就应该考虑分布式文件系统了。

业务继续发展，单台服务器存储和响应也很快到达了瓶颈，新的业务需要文件访问具有高响应性、高可用性来支持系统。分布式文件系统，一般分为三块内容来配合，服务的存储、访问的仲裁系统，文件存储系统，文件的容灾系统来构成，仲裁系统相当于文件服务器的大脑，根据一定的算法来决定文件存储的位置，文件存储系统负责保存文件，容灾系统负责文件系统和自己的相互备份。

• 优点：扩展能力: 毫无疑问，扩展能力是一个分布式文件系统最重要的特点；高可用性: 在分布式文件系统中，高可用性包含两层，一是整个文件系统的可用性，二是数据的完整和一致性；弹性存储: 可以根据业务需要灵活地增加或缩减数据存储以及增删存储池中的资源，而不需要中断系统运行
• 缺点：系统复杂度稍高，需要更多服务器

2. FastDFS

FastDFS是一个开源的轻量级分布式文件系统。它解决了大数据量存储和负载均衡等问题。特别适合以中小文件（建议范围：4KB < file_size [storage server list]的映射表。

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

2.2.2 storage server

存储服务器（又称：存储节点或数据服务器），文件和文件属性（meta data）都保存到存储服务器上。Storage server直接利用OS的文件系统调用管理文件。

Storage server（后简称storage）以组（卷，group或volume）为单位组织，一个group内包含多台storage机器，数据互为备份，存储空间以group内容量最小的storage为准，所以建议group内的多个storage尽量配置相同，以免造成存储空间的浪费。

以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的方式被路由到其中某个子目录下，然后将文件数据直接作为一个本地文件存储到该目录中。

2.2.3 client

客户端，作为业务请求的发起方，通过专有接口，使用TCP/IP协议与跟踪器服务器或存储节点进行数据交互。FastDFS向使用者提供基本文件访问接口，比如upload、download、append、delete等，以客户端库的方式提供给用户使用。

另外两个概念：

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

2.3 优缺点

优点：

• 机器配置要求低。不管是上传下载，同步恢复，都对机器的负载要求非常低。
• 支持相同内容的文件只保存一份，节约磁盘空间
• 支持在线扩容机制，增强系统的可扩展性
• 支持主从文件，支持自定义扩展名
• 主备Tracker服务，增强系统的可用性

缺点：

• 不支持断点续传，对大文件将是噩梦(FastDFS不适合大文件存储)
• 对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略
• 同步机制不支持文件正确性校验，降低了系统的可用性

2.4 上传下载交互过程

上传交互过程：

• client询问tracker上传到的storage，不需要附加参数；
• tracker返回一台可用的storage；
• client直接和storage通讯完成文件上传。

下载交互过程：

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

2.6 文件ID-FID

文件索引结构如下图，是客户端上传文件后存储服务器返回给客户端，用于以后访问该文件的索引信息。文件索引信息包括：组名，虚拟磁盘路径，数据两级目录，文件名。

• 组名：文件上传后所在的存储组名称，在文件上传成功后有存储服务器返回，需要客户端自行保存。
• 虚拟磁盘路径：存储服务器配置的虚拟路径，与磁盘选项store_path*对应。
• 数据两级目录：存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储数据文件。
• 文件名：与文件上传时不同。是由存储服务器根据特定信息生成，文件名包含：源存储服务器IP地址、文件创建时间戳、文件大小、随机数和文件拓展名等信息。

如何快速定位文件？

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

• 通过组名tracker能够很快的定位到客户端需要访问的存储服务器组，并将选择合适的存储服务器提供客户端访问；
• 存储服务器根据“文件存储虚拟磁盘路径”和“数据文件两级目录”可以很快定位到文件所在目录，并根据文件名找到客户端需要访问的文件。

3. 文件系统的对比 指标适合类型文件分布系统性能复杂度FUSEPOSIX备份机制通讯协议接口社区支持开发语言FastDFS4KB~500MB小文件合并存储不分片处理很高简单不支持不支持组内冗余备份Api HTTP国内用户群C语言TFS所有文件小文件合并，以block组织分片复杂不支持Block存储多份,主辅灾备API http少C++MFS大于64K分片存储Master占内存多支持支持多点备份动态冗余使用fuse挂在较多PerlHDFS大文件大文件分片分块存储简单支持支持多副本原生api较多JavaCeph对象文件块OSD一主多从复杂支持支持多副本原生api较少C++MogileFS海量小图片高复杂可以支持不支持动态冗余原生api文档少PerlClusterFS大文件简单支持支持多C 4. 安装部署 4.1 docker安装

1.准备docker启动文件

vim start.sh

docker stop fastdfs
docker rm fastdfs
docker run \
        --net=host \
        --name=fastdfs \
        -e IP=192.168.28.130 \
        -e WEB_PORT=80 \
        -v $PWD/fdfs:/var/local/fdfs \
        -d registry.cn-beijing.aliyuncs.com/tianzuo/fastdfs

确保80、22122和23000这3个端口未被占用

IP：配置所在服务器的ip WEB_PORT：配置nginx的端口，用于文件下载

2.运行

sh start.sh

3.测试

docker exec -it fastdfs /bin/bash

echo "Hello FastDFS!">index.html

fdfs_test /etc/fdfs/client.conf upload index.html

执行后的返回url： 通过返回的url访问文件：

4.2 本地安装

具体安装方法查看官网wiki：https://github.com/happyfish100/fastdfs/wiki

生产级别的部署架构图：

统一的对外下载访问入口的高可用架构，其中所有的Nginx只做下载用途，上传通过tracker进行上传