分布式文件存储选型考虑点

 

目前市面上有的开源产品包括：

• 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个节点成功就返回成功？

2. 如果上传到1个节点就成功，其他节点正在同步数据时，立即瞬间删除文件，程序应该如何处理？

3. 如果同步过程中，有部分节点同步数据失败怎么办？

4. 有部分节点在收到删除但还未执行时，服务器突然挂了怎么办？

5. 允不允许修改已上传的文件？如果允许，那么修改到一半的时候，突然断电，文件是否就损坏了？

6. 支不支持断点续传，断点续传过程中突然断电，上次还能否接着上传而数据不损坏？

7. 新增存储节点后，会不会重新分配和迁移之前的数据？

8. 新增的存储节点刚刚加入集群，然后立马关闭或者意外挂掉，集群状态会不会混乱，数据会不会异常？

9. N个存储节点N个副本，如果挂掉一个节点，服务还能否使用，如果能使用，那上传的文件会有几个副本？

10. 挂掉一个存储节点后，运行了一段时间，上传了很多文件，当这个节点恢复了，会同步之前上传的文件到这个节点吗？

 

    因此要考虑的问题还很多，而且不少问题看似很苛刻，但是我确实也遇到过。作为一个分布式文件系统，不得不考虑它的安全稳定性啊，上面提到的这些点，都应该做下测试。