分布式文件存储选型考虑点
2018年10月21日


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

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


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