首先，看下这几篇文章：
总体思路：
专题分析：
1、SeaweedFS
参见我的这篇文章《分布式文件存储SeaweedFS试用对比总结》。
2、MinIO
参见我的这篇文章《分布式文件存储MinIO试用对比总结》
3、FastDFS
参见我的这几篇文章《FastDFS的一些缺点（强烈需要注意）》《FastDFS集群部署和使用》
4、还有一些我没仔细看过的，简单分析一下
比如：
Ceph：https://github.com/ceph/ceph
GlusterFS：https://github.com/gluster/glusterfs，https://www.gluster.org
MooseFS：https://github.com/moosefs/moosefs
GridFS：https://docs.mongodb.com/manual/core/gridfs/
简单看了下MooseFS社区，不够活跃，而且有些高级功能要Pro版才有。
而GridFS，是MongoDB的一部分，不像是专业的分布式文件系统。
总之，目前来看，开源的分布式文件存储，就4选一吧：MinIO、SeaWeedfs、GlusterFS、Ceph！
但是据说，GlusterFS小文件存储不如SeaWeedfs，参见：https://blog.csdn.net/karamos/article/details/80130751
另外，有人不建议用Ceph：“After working with Ceph for 11 months I came to conclusion that it utterly sucks(糟糕透了) so I suggest to avoid it.”，参见：https://stackoverflow.com/questions/17425153/distributed-file-systems-gridfs-vs-glusterfs-vs-ceph-vs-hekafs-benchmarks，另外我发现SeaWeedfs居然是2013年开始的，也算非常老牌的了，毕竟2012年Golang才发布第一版！
SeaWeedFS官方有与Ceph的对比，参见：
https://github.com/chrislusf/seaweedfs#compared-to-other-file-systems
https://github.com/chrislusf/seaweedfs/issues/120
综合了很多信息，我优先选择了 MinIO 和 SeaweedFS进行试用。
MinIO 和 SeaweedFS 简单对比
MinIO是N个磁盘，可以任意损坏N/2个，而数据不会丢失，但是这种情况下只能读，不能写，如果有N/2+1个磁盘完好，则可以读写。实际磁盘空间占用，我的测试结果为：一个31,294,295 b的文件，10个磁盘的情况下，每个磁盘分到恰好6258955 b，占用总磁盘空间是单个文件size的恰好2倍。另外，我还测过4个磁盘的情形，总size也是单个文件的2倍。
而SeaweedFS的说明如下：
SeaweedFS implemented RS(10,4), which allows loss of 4 shards of data with 1.4x data size. Compared to replicating data 5 times to achieve the same robustness, it saves 3.6x disk space.
If up to 4 shards are down, the data is still accessible with reasonable speed.
翻译：SeaweedFS允许10个分片，挂掉4个，而数据仍然可以读，数据size为单个的1.4倍。如果要通过全量复制达到相同的效果，允许挂掉一个，那就需要4+1=5个分片。
换句话说，一个10M的文件，SeaweedFS将其存放在10个分片上，一共才占用14M的空间，达到的效果是可以挂掉4个分片。而如果要通过全量复制的方式，要5个分片，占用的空间为50M。节省了36M磁盘空间，节省了36/50=72%，同样，分片越多，节省得越多。
和MinIO对比一下，MinIO要达到挂掉4个分片可以，只需要8个分片，但是占用空间为20M，节省了60%的空间。这方面不如SeaweedFS的72%，但是可以节省2个分片。
另外，说一下我遇到的问题，MinIO在10个分片的时候，启动非常慢，也可能是我虚拟机的配置非常低问题（1cpu+1G内存，带动10个分片的MinIO），但是侧面也说明MinIO资源占用非常低，1G内存居然可以带动10个分片！
SeaweedFS
SeaweedFS将磁盘进行了分组，分为DataCenters、Racks（机架），Servers和Hard Drive，从而保证了更高的可用性。像MinIO那样，volume是没有分组的，文件分布没有权重，感觉是要差一点。
SeaweedFS兼容Amazon S3的大多数常用API，同样SeaweedFS也支持命令行管理文件，以及HTTP API，且支持将虚拟文件系统挂载到操作系统上（FUSE），这样的话，操作文件甚至比Browser更方便有木有！
另外，SeaweedFS支持两个集群之间的数据全量或实时同步（借助Kafka等MQ），这在跨数据中心同步文件时很重要。同时，这个功能可以将数据实时备份到云存储（Amazon S3, Google Cloud Storage, Azure,阿里云等）。
还支持纠删码（Erasure Coding for warm storage），貌似是很牛逼的功能。
说下SeaweedFS的缺点吧：中小型文件效率非常高，但是它的单卷最大容量被程序限制到30GB，对超大文件（比如500MB以上），我感觉它的设计不是很占优势。我建议存储的文件以100MB以内的为主（当然，有少数较大的文件也没任何问题）。
具体参见我的这篇文章《分布式文件存储SeaweedFS试用对比总结》。