针对新增加的文件更新需求来看，在项目整体的需求中，在分布式的需求设计中，单机存储已不再满足现有的系统设计，需要为系统增加一个存储服务系统。

选择

在各类开源的存储文件系统中，前后主要了解过MongoDB的GridFS，bilibili的bfs，淘宝的TFS，MinIO以及fastdfs。

GridFS，用于存储和恢复那些超过16M的文件，相当于对MongoDB本身Bson存储容量的一个扩展；

MinIO，同样是存储大容量非结构化的数据所设计，且由于核心算法的需要，集群搭建至少4台机器起，且组件过大，后期维护；

TFS，在搭建操作时，由于一直看到搭建复杂，维护不太方便，故放弃；

bfs和fastdfs，bfs是B站为自家网站设计的图片存储系统，fastdfs更适用大众一些，其算起来都不算是一个完整的微型文件系统，当然，在这里，我们需要的是一个文件存储服务系统。

综合来看，选择fastdfs似乎是当下适合的选择。

延伸

fastdfs还有一个Go仓库与之类似，但并不是原仓库作者开发，go-fastdfs，虽然作者是号称类fastdfs，但其实还是不太一样的，存储文件方式可能是类似。

但go-fastdfs是有元数据的存储的（使用leveldb存储），而fastdfs无元数据的存储，当无分布式算法的一致性特性的保证下，元数据的可用性将存在可用性存疑的问题。

虽然go-fastdfs使用Go开发，操作维护也简便，但出于服务整体的稳定性考虑，还是优先选择fastdfs靠谱一点，毕竟已经经过社区与作者的多年开发及维护，基本全线生产可用，对于本项目来说，已经是完全够用了。

缺点

fastdfs虽然经历了多年的开发迭代，且用于生产环境的公司不少，但还是没有一个完整的介绍文档，显然是一个很大的缺陷，遇到问题大概有两个地方可以寻求帮助：分布式文件系统（FastDFS）和fastdfs issue。

另外一点就是，Go下的fastdfs client不是官方开发，第三方的仓库也早已经不再开发，简单使用测试没有问题，在分布式下是否会出现问题不太清楚，这块也需要关注，在后期可能也要投入精力。