FastDFS 海量小文件存储解决之道

2022-04-26 519

作者：vivo互联网服务器团队-Zhou Changqing

一、FastDFS原理介绍

FastDFS是一个C语言实现的开源轻量级分布式文件系统。

支持 Linux、FreeBSD、AID 等Unix系统，解决了大容量的文件存储和高并发访问问题，文件存取实现了负载均衡，适合存储 4KB~500MB 之间的小文件，特别适合以文件为载体的在线服务，如图片、视频、文档等等。

二、FastDFS 架构

FastDFS 由三个部分构成：

客户端（Client）
跟踪服务器（TrackerServer）
存储服务器（StorageServer）

2.1 Tracker Server (跟踪服务器)

Tracker Server (跟踪服务器) 主要是做调度工作，起到负载均衡的作用。

**（1）【服务注册】**管理StorageServer存储集群，StorageServer启动时，会把自己注册到TrackerServer上，并且定期报告自身状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。

**（2）【服务发现】**Client访问StorageServer之前，必须先访问TrackerServer，动态获取到StorageServer的连接信息，最终数据是和一个可用的StorageServer进行传输。

（3）【负载均衡】

store group分配策略：

0：轮询方式

1：指定组

2：平衡负载(选择最大剩余空间的组(卷)上传)

store server分配策略：

0：轮询方式

1：根据 IP 地址进行排序选择第一个服务器（ IP 地址最小者）

2：根据优先级进行排序（上传优先级由storage server来设置，参数名为upload_priority）

stroe path分配：

0：轮流方式，多个目录依次存放文件

2：选择剩余空间最大的目录存放文件（注意：剩余磁盘空间是动态的，因此存储到的目录或磁盘可能也是变化的）

2.2 Tracker Server (跟踪服务器)

Tracker Server (跟踪服务器) 主要提供容量和备份服务。

**【分组管理】**以Group为单位，每个Group包含多台Storage Server，数据互为备份，存储容量以Group内容量最小的 storage 为准，已 Group 为单位组织存储方便应用隔离、负载均衡和副本数据定制。

**缺点：**Group容量受单机存储容量的限制，数据恢复只能依赖Group其他机器重新同步。

**【数据同步】**文件同步只能在 Group 内的Storage Server之间进行，采用push方式，即源服务器同步给目标服务器。源服务器读取 binlog 文件，将文件内容解析后，按操作命令发送给目标服务器，有目标服务按命令进行操作。

三、上传下载流程

3.1 上传流程解析

3.1.1 选择Tracker Server

集群中的 tracker 之间都是对等的，客户端在上传文件时可任意选择一个 tracker 即可。

3.1.2 分配Group、Stroage Server 和storage path（磁盘或者挂载点）

tracker 接收到上传请求时会先给该文件分配一个可以存储的 Group ，然后在Group中分配一个Storage Server给客户端，最后在接收到客户端写文件请求时，Storage Server 会分配一个数据存储目录并写入。

（该过程中的分配策略详见：【负载均衡】）

3.1.3 生成file_id写入并返回

Storage 会生成一个 file_id 来作为当前文件名，file_id 采用 base64 编码，包含：源 storage server ip、文件创建时间、文件大小、文件CRC32校验码和随机数。每个存储目录下有两个256*256个子目录。

Storage 会根据 file_id 进行两次 hash 路由到其中一个子目录中。

最后以file_id为文件名存储文件到该子目录下并返回文件路径给客户端。

最终文件存储路径：

**分组 |磁盘|子目录| 文件名 **

group1/M00/00/89/eQ6h3FKJf_PRl8p4AUz4wO8tqaA688.apk

【分组】：文件上传时分配 Group。
【磁盘路径】：存储服务器配置的虚拟路径，对应配置参数 store_path 例如：M00对应store_path0，M01对应store_path1。
【两级目录】：存储服务器在每个虚拟磁盘路径下创建的两级目录，用于存储文件。

3.2 下载流程解析

3.2.1 解析路径并路由

tracker 接收 client 发送的下载请求时，tracker 从文件名中解析出 Group、大小、创建时间等信息，然后根据Group 选择一个 storage server 返回。

3.2.2 校验读取并返回

客户端和 Storage Server 建立链接，校验文件是否存在，最终返回文件数据。

**缺点：**Group之间文件同步是异步进行的，可能上传的文件还未同步到当前访问的 Storage Server 这台机器上或者延迟原因，将导致下载文件出现404。所以引入nginx_fastdfs_module 可以很好的解决同步和延迟问题。

3.3 引入fastdfs_nginx_module组件后的下载架构

FastDFS Nginx Module功能介绍

（1）【防盗链检查】

利用 FastDFS nginx 扩展功能动态生成token，设置http.conf 配置。

开启防盗链功能

http.default_content_type =

application/octet-stream

http.mime_types_filename=mime.types

开启token防盗链功能

http.anti_steal.check_token=true

token过期时间

http.anti_steal.token_ttl=900

密钥

http.anti_steal.secret_key=xxx

token 过期后返回的内容

http.anti_steal.token_check_fail=/etc/fdfs/anti-steal.jpg

【token 生成算法】：md5(fileid_without_group + privKey + ts) 同时ts没有超过 ttl 范围。

服务器会自动根据token,st 以及设置的秘钥来验证合法性。访问链接形式如：

http://localhost/G1/M00/00/01/wKgBD01c15nvKU1cAABAOeCdFS466570.jpg?token=b32cd06a53dea4376e43d71cc882f9cb&ts=1297930137

（2）【文件元数据解析】

根据 file_id 获取元数据信息, 包括：源storage ip，文件路径，名称，大小 等。

（3）【文件访问路由】

因文件的file_Id 包含了上传文件时的源 Storage Server IP ，所以在获取不到本机下的文件时（未同步或者延迟情况下）FastDFS 扩展组件，会根据源服务器IP 来重定向或者代理方式获取文件。

重定向模式

配置项response_mode = redirect，服务器返回302，重定向url

http://源storage ip:port/文件路径?redirect=1

代理模式

配置项response_mode = proxy，使用源storage 地址作为代理proxy的host，其他部分不变

四、同步机制

4.1 同步规则

同步只发生在本组的 Storage Server 之间。

源头数据才需要同步，备份数据不需要再次同步。

新增 Storage Server 时，会由已有一台 Storage Server 将已有的所有数据（源头数据和备份数据）同步给新增服务器。

4.2 Binlog 复制

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

时间戳 | 操作类型 | 文件名

1490251373 C M02/52/CB/CtAqWVjTbm2AIqTkAAACd_nIZ7M797.jpg

操作类型（部分）：

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

4.3 同步流程

新增 Storage Server 后，组内其他 Storage Server 服务器会启动同步线程，在 tracker的协调下向新增服务器发起全量和增量同步操作。

（1）Storage C启动后向tracker 上报所属group、ip、port、版本号、存储目录数、子目录数、启动时间、老数据是否同步完成，当前状态等信息。

（2）tracker 收到Storage C 加入申请请求后，更新本地storage list，返回给C，并适时同步给A、B。

（3）storage C向tracker 申请同步请求，响应后变更自身状态为WAIT_SYNC。

（4）storage A 和B 在心跳周期内从同步到的新storage list 发现没有C，则启动同步线程，先向tracker发起同步申请（TRACKER_PROTO_CMD_STORAGE_SYNC_SRC_REQ）,tracker会把同步源IP级同步时间戳返回给A和B,如果源IP和自己本地IP一致，则标记自己作为同步源用来做老数据同步（全量同步源），如果不一致，则标记自己作为增量同步源（只有在C节点状态为Active时才同步）。该决策是由tracker 选择产生的，不可A、B同时作为同步源，同时同步给C。

（5）同步源（假设是storage A）以 .mark为后缀的文件记录目标机器同步信息，并上报变更storage C状态为SYNCING。

（6）从/data.sync目录下读取binlog.index 中的，binlog文件Id，binlog.000读取逐行读取，进行解析.(详见上面binlog 内格式) 发送数据给storage C ，C接收并保存。

（7）数据同步过程中 storage C 的状态变更过程OFFLINE->ONLINE->ACTIVE。ACTIVE 是最终状态，表示storage C 已对外提供服务。

五、文件存储

5.1 LOSF问题

小文件存储（LOSF）面临的问题：

本地文件系统innode梳理优先，存储小文件数量受限。
目录层级和目录中文件数量会导致访问文件开销很大（IO次数多）。
小文件存储，备份和恢复效率低。

针对小文件存储问题，FastDFS 提供了文件合并解决方案。FastDFS 默认创建大文件为 64M，大文件可以存储很多小文件，容纳一个小文件的空间叫slot，solt 最小256字节，最大16M。小于256字节当256字节存储，超过16M文件单独存储。

5.2 存储方式

**（1）【默认存储方式】**未开启合并，FastDFS生成的file_id 和磁盘上实际存储的文件一一对应。

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

如下：

【file_size】：占用大文件的空间（注意按照最小slot-256字节进行对齐）

【mtime】：文件修改时间

【crc32】：文件内容的crc32码

【formatted_ext_name】：文件扩展名

【alloc_size】：文件大小与size相等

【id】：大文件ID如000001

【offset】：文件内容在trunk文件中的偏移量

【size】：文件大小。

5.3 存储空间管理

**（1）【Trunk Server】**由tracker leader 在一组Storage Server 选择出来的，并通知给该组内所有Storage Server，负责为该组内所有upload操作分配空间。

**（2）【空闲平衡树】**trunk server 会为每个store_path构造一个空闲平衡树，相同大小的空闲块保存在链表中，每次上传请求时会到根据上传的文件大小到平衡树中查找获取大于或者接近的空闲块，然后从空闲块中分割出多余的作为新的空闲块，重新加入平衡树。如果找不到则会重建一个新的trunk文件，并加入到平衡树中。该分配过程即是一个维护空闲平衡树的过程。

**（3）【Trunk Binlog】**开启了合并存储后，Trunk Server 会多出一个TrunkBinlog同步。TrunkBinlog记录了TrunkServer 所有分配与回收的空闲块操作，并由Trunk Server同步给同组中其他storage server。

TrunkBinlog格式如下：

时间戳 | 操作类型 | store_path_index | sub_path_high| sub_path_low | file.id| offset | size 1410750754 A 0 0 0 1 0 67108864

各字段含义如下：

【file.id】：TrunkFile文件名，比如 000001

【offset】：在TrunkFile文件中的偏移量

【size】：占用的大小，按照slot对齐

六、文件去重

FastDFS不具备文件去重能力，必须引入FastDHT 来配合完成。FastDHT 是一个键值对的高效分布式hash系统，底层采用Berkeley DB 来做数据库持久化，同步方式使用binlog复制方式。在FastDFS去重场景中，对文件内容做hash，然后判断文件是否一致。

在文件上传成功后，查看 Storage存储对应存储路径，会发现返回的是一个软链接，之后每次重复上传都是返回一个指向第一次上传的文件的软链接。也就保证了文件只保存了一份。

（注意：FastDFS不会返回原始文件的索引，返回的全部都是软链接，当所有的软链接都被删除的时候，原始文件也会从FastDFS中被删除）。

七、总结

FastDFS 真正意义上只是一个管理文件的系统（应用级文件系统），比如管理上传文件、图片等。并不像系统磁盘文件系统NTFS或者FAT 等这种系统级文件系统。

微信关注我们

原文链接：https://my.oschina.net/vivotech/blog/5519663

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

一文详解Java日志框架JUL

摘要：JUL（Java util logging），Java原生日志框架，不需要引入第三方依赖包，使用简单方便。本文分享自华为云社区《Java 日志框架 JUL 详解大全》，作者：陈皮的JavaLib 。 JUL 简介 JUL（Java util logging），Java 原生日志框架，不需要引入第三方依赖包，使用简单方便，一般在小型应用中使用，主流项目中现在很少使用了。 JUL 架构 Application：Java 应用程序。 Logger：记录器，Java 应用程序通过调用记录器的方法来发布日志记录。 Handler：处理器，每一个 Logger 都可以关联一个或多个 Handler，Handler 从 Logger 获取日志并将日志输出到某个目的地，目的地可以是控制台，本地文件，或网络日志服务，或将它们转发到操作系统日志等等。通过Handler.setLevel(level.off)方法可以禁用一个 Handler，也可以设置其他级别来开启此 Handler。 Filter：过滤器，根据条件过滤哪些日志记录。每一个 Logger 和 Handler 都可以关联一个 Fil...

2022-04-26

490

文 @ 不愿透露姓名的小 P 同学前言大家好，本次分享的主题是业界知名的 AI 编译框架 TVM 的一个子模块——ANSOR。ANSOR 可以对 AI 模型做自动优化，解决代码生成中的自动调度问题。近几年，AI 算法和硬件领域都了获得巨大的发展，深度学习网络中的新算子和用于运行深度学习网络的新硬件层出不穷。在传统的深度学习框架中，如果需要支持一个新算子，首先需要将算子对接到硬件厂商提供的计算库，如果计算库不支持这个算子，则需要通过手写算子来实现算子支持，而对于不同的硬件设备，往往需要分别手写对应硬件设备的算子来完成支持，这就会导致深度学习框架的算子支持工作量巨大。另一方面，以算子为粒度的深度学习框架也不利于深度学习网络的优化，一个典型的例子是算子融合。在深度学习框架中，算子融合优化需要提供融合算子的模板（如[CONV, BN, RELU]），然后根据模板将匹配到的算子替换为一个手写的融合算子。然而，算子的融合策略往往是不可数的，所以，这种方式不但实现起来复杂，而且很难遍历到所有的优化空间。 TVM 作为深度学习编译器，首先将深度学习网络转换为其内部的 IR，这个 IR 可以对深...

2022-04-26

496

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。