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

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

   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）。

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

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

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

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

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

本文分享自微信公众号 - FastDFS分享与交流（fastdfs100）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。