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

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

• 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. 挂掉一个存储节点后，运行了一段时间，上传了很多文件，当这个节点恢复了，会同步之前上传的文件到这个节点吗？

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

最后

以上就是过时小馒头为你收集整理的分布式文件存储选型考虑点的全部内容，希望文章能够帮你解决分布式文件存储选型考虑点所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。