介绍

FastDFS是一款开源文件存储服务软件，便于存储非结构化文档。其特点如下：

存储的文件名会被重新命名成看似随机字符串的结构，实际上有相应的规则。
既可以动态增加文件副本，又可以动态横向扩展增加集群的总容量。
使用文件存储集群状态，而不是关系数据库。
不支持账号权限管理文件。
文件以原本方式直接存储到文件系统中，未加密。

根据以上特点，可知FastDFS适用于内网安全环境下，图片和视频等文件的管理。

更新日志

2022-08-31 初稿

架构

FastDFS服务分为tracker server和storage server，都支持集群部署。其中tracker server负责调度，当客户端请求文件管理时，首先访问tracker server，tracker server根据接受到注册的storage server的列表和其状态，决定将请求分配给哪个storage server，然后返回该storage server的ip和端口给客户端，客户端再对storage server直接发起请求。

FastDFS架构图.drawio.png

存储结构

FastDFS集群下，可以划分多个group，最简单的情况只有一个group，即group1。当group1存储节点存储空间不足时，可以新增一个group, 可以是group2，这个时候新的文件会存储到group2中，就实现了Fastdfs的横向扩容。

group1中的文件，单节点的情况下只存储一份，损坏了就没有了，这时候可以往group1中加入另一个存储节点，这样存储到group1的文件就会存储两份，其中任意一个存储节点宕机，也不影响整个集群的使用。

FastDFS存储结构.drawio.png

Storage的多path挂载

虽然我们可以使用raid阵列来将多个硬盘模拟成一个，也可以使用linux的lvm来模拟，但是单独硬盘也有其优势，那就是更换后只需要修复损坏部分的内容即可，fastdfs支持该场景，这里看看如何配置

配置说明

store_path_count

# path(disk or mount point) count, default value is 1
# must same as storage.conf

该参数对使用了的store_path进行计数，mod_fastdfs.conf和storage.conf中，将该参数修改成正确的值，默认只有store_path0配置了路径，store_path_count为1

store_path

# which path(means disk or mount point) of the storage server to upload file
# 0: round robin
# 2: load balance, select the max free space path to upload file

该参数用于设置多个store_path路径的情况下，上传的文件选择哪个路径的计算方法，0为轮询，2为根据剩余空间决定使用哪个路径。实测情况下，使用2会有效果，但是计算不是很及时，空间小的时候容易被撑满，空间大时应该影响不大。

base_path

# the base path to store data and log files
base_path=/var/local/fdfs/storage

基础路径，日志必存这个路径，一般和store_path0一致，也可以拆分开。

store_path0

# store_path#, based 0, if store_path0 not exists, it's value is base_path
# the paths must be exist
store_path0=/var/local/fdfs/storage

基础路径，一般只有一个存储路径的话，默认这个就可以了，或者修改成适当的路径。如果有多个存储路径，则在下面跟上对应的路径即可，这里举例：

store_path1=/var/local/fdfs1/storage
store_path2=/var/local/fdfs2/storage
store_path3=/var/local/fdfs3/storage
store_path4=/var/local/fdfs4/storage

当然这个时候，store_path_count参数也得修改成对应的数量，记得要修改mod_fastdfs.conf和storage.conf这两个文件。

多硬盘存储模式下，单盘损坏测试

模拟手段

将该盘只读挂载，参考命令mount -r /dev/sdc1 /mnt/disk2，执行之前，确保/mnt/disk2已卸载，docker挂载了的话，得先停docker才能只读挂载。

测试场景1，只读挂载数据盘所在得服务未停止

上传数据时会报错，并终止上传。

[2022-08-12 10:20:45] ERROR - file: ../client/storage_client.c, line: 996, fdfs_recv_response fail, result: 30
upload file fail, error no: 30, error info: Read-only file system

可以想象，如果是硬盘损坏，这里得内容会替换成硬盘不可访问类似的内容。应用未自动识别到某个节点的坏盘，并忽略该节点，而是任意失败都终止业务，所以得出结论：

一旦任意数据盘损坏，Fastdfs将不可写入

读取不用测试，不能写入就已经影响业务了，能不能读不重要了。

测试场景2，只读挂载数据盘所在得服务已停止

上传数据时仍然会有报错，但是会上传成功。

[2022-08-12 10:23:06] ERROR - file: connection_pool.c, line: 130, connect to 192.168.145.133:22122 fail, errno: 111, error info: Connection refused
group1/M01/00/6D/wKiRhmL1uYqATZ1cAAATUTRHA2M3521664

可以将该场景看作双节点架构，其中一个停止服务的场景，业务可以运行。将问题节点硬盘问题修复后，启动Fastdfs服务，再次期间产生的新文件会自动同步过去。

测试结论：一旦任意数据盘损坏，Fastdfs将不可写入，写入业务就会停止，需要立即干预，将问题节点的Fastdfs服务停服，最好是有监控，一旦触发，自动将其停服。

双活高可用测试

服务器上删除其中一个节点的storage下的数据

删除个别文件，无论是否重启，证实无法从有数据的节点自动同步数据过来。
删除storage目录，不重启无法同步数据过来，重启后数据会同步过来

服务器上的某个磁盘损坏

模拟磁盘损坏之后重新拔插磁盘，数据完全丢失后重启服务，数据可以自动同步过来，是上面的第二个场景。

【FastDFS】原理

介绍