FastDFS集群部署指南

Posted 2021-08-08 Huazie

FastDFS集群部署指南

本篇文章转载于FastDFS作者 余庆 大佬的 FastDFS分享与交流 公众号。

FastDFS server 端有两个角色，tracker server 和 storage server。

1. tracker server

tracker server 只管理集群拓扑数据，不会存储任何文件索引，因此 tracker server 对服务器的硬件配置要求较低。为了实现互备，tracker server 通常两台就够了。tracker server 占用资源较少，如果集群规模较小（比如只有一组storage server），可以复用 storage server。

2. storage server

storage server 提供文件存储的IO密集型服务。FastDFS 存储文件是直接基于操作系统的文件系统的，storage server 的性能瓶颈通常表现为磁盘 IO。为了充分利用磁盘 IO，推荐不做 RAID，直接挂载单块硬盘，每块硬盘 mount 为一个路径，作为 storage server 的一个 store path。为了充分利用文件系统的 cache 以加快文件访问速度，推荐 storage server 配置较大内存，尤其存在众多热点文件的场合下。大量的 IO 吞吐也会消耗一定的 CPU，因此storage server 对 CPU 核数也有一定要求。

为了相互备份，一个 group 的 storage server 通常有两台即可。如果对数据可靠性要求很苛刻，一个 group 可以有三台甚至更多 storage server。因一个 group 内的 storage server 对文件采用 冗余备份的RAID1 方式，文件写入性能 不会随 storage server 的增加而增加，理论上文件读取性能 随着 storage server 的增加而线性增加。

3. FastDFS client API

FastDFS client API 方面，目前官方提供了 C、PHP extension 和 Java的client API（GitHub：happyfish100/fastdfs-client-java）。对于互联网应用，文件上传和删除等操作必须使用 FastDFS client API，文件下载建议采用 HTTP 方式。推荐使用 nginx扩展模块，每台 storage server 均需要部署 nginx（GitHub：happyfish100/fastdfs-nginx-module）。

4. 两大特性使用建议

下面针对 V3 的 小文件合并存储 以及 V4 的 storage server id（以 id 而不是 IP 来标识 storage server）这两大特性给出使用建议。

4.1 小文件合并存储

海量小文件场景，比如一个 group 存储的文件数可能上千万甚至上亿，建议使用文件合并存储特性，在 tracker.conf 中设置 use_trunk_file=1。因文件合并存储存在额外开销，如果一个 group 存储的文件数不超过一千万，就没有必要使用这个特性了。FastDFS支持一开始没有使用合并存储，后来觉得有需要再打开这个特性；反之也是可以的。

4.2 storage server id

为了避免不必要的干扰以及安全考虑，建议使用 storage server id 方式。tracker.conf 中设置 use_storage_id=1。并将 storage server id、ip 和分组配置到 storage_ids.conf中。storage server 一开始采用默认的 IP 标识方式运行，后面也可以切换到 server id 标识方式。反之（id 方式切换到 IP 方式）则是开历史倒车存在隐患，不可取也没有必要这么做。

4.3 优势总结

由上面两点可以看出 FastDFS 引以为傲的两个优势：架构稳定性和数据兼容性。FastDFS 程序升级只需要覆盖程序即可，而数据兼容问题，FastDFS 在代码中默默地完成了。FastDFS 理论上可以从 V1 直接平滑升级到目前的 V6，至少两个相邻的大版本间升级是无缝的（比如 V4 升级到 V5，V5 升级到 V6）。

FastDFS 的惯例是老版本不再维护，推荐大家使用 FastDFS 最新版本（当前版本v6.01）。请大家迈开步子，放心大胆地升级吧。