目前市面上有的开源产品包括：
GridFS（MongoDB的一部分，https://docs.mongodb.com/manual/core/gridfs/）
FastDFS（https://github.com/happyfish100/fastdfs）
TFS（https://github.com/alibaba/tfs）
SeaweedFS（https://github.com/chrislusf/seaweedfs）
HBASE（HDFS）
Ceph(https://github.com/ceph/ceph)
MooseFS（https://moosefs.com/）
GlusterFS（http://www.gluster.org/）
MinIO（https://docs.min.io/cn）
入围标准参见《中间件选型标准和流程》，在此不再多说。
本文只就 分布式文件存储系统 的特点和需求，来说下选型的考虑点。
考虑以下几点：
高性能
安全性/容错性高、数据万无一失
资源占用较小、运行稳定
高可用、支持集群、支持多活
支持平滑的扩容
较高的并发
1）高性能上，主要考虑500M以内的小文件，特别是10M以内的文件。
2）安全性上，要考虑各种极端情况，包括网络异常，服务器断电，磁盘损坏等。
3）高并发可能也要考虑，比如用户上传文件，当用户量很大时，文件服务器的并发压力也会很大。
以常见的分布式存储FastDFS为例，假设有1个负责寻址的trackServer节点和3个负责存储的storage节点组成的集群，上传的文件，要同步到3个storage节点上：
是所有节点数据同步成功才上传成功，还是上传到1个节点成功就返回成功？
如果上传到1个节点就成功，其他节点正在同步数据时，立即瞬间删除文件，程序应该如何处理？
如果同步过程中，有部分节点同步数据失败怎么办？
有部分节点在收到删除但还未执行时，服务器突然挂了怎么办？
允不允许修改已上传的文件？如果允许，那么修改到一半的时候，突然断电，文件是否就损坏了？
支不支持断点续传，断点续传过程中突然断电，上次还能否接着上传而数据不损坏？
新增存储节点后，会不会重新分配和迁移之前的数据？
新增的存储节点刚刚加入集群，然后立马关闭或者意外挂掉，集群状态会不会混乱，数据会不会异常？
N个存储节点N个副本，如果挂掉一个节点，服务还能否使用，如果能使用，那上传的文件会有几个副本？
挂掉一个存储节点后，运行了一段时间，上传了很多文件，当这个节点恢复了，会同步之前上传的文件到这个节点吗？
因此要考虑的问题还很多，而且不少问题看似很苛刻，但是我确实也遇到过。作为一个分布式文件系统，不得不考虑它的安全稳定性啊，上面提到的这些点，都应该做下测试。