Java常用分布式文件系统调研

1.背景简介
应对开发需求，亟需合适的文件系统对图片文件进行管理。目前调研文件系统需要满足以下几点：
1）图片量级非常大；
2）图片大小为4MB左右。
3）便于快速查询。
4）分布式部署和存储文件。
5）数据查询能做到负载均衡。
6）对开发人员友好。
7）拓展方便。

2.适用范围

3.术语定义

4.参考文档

5.常用分布式文件系统

5.1FastDFS

5.1.1概述
FastDFS是一款开源的分布式文件系统，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合中小文件（建议范围：4KB < file_size <500MB）。

5.1.2架构
FastDFS架构包括Tracker server和Storage server。客户端请求Tracker server进行文件上传、下载，通过Tracker server调度最终由Storage server完成文件上传和下载。
1）跟踪服务器Tracker Server
主要做调度工作，起到均衡的作用；负责管理所有的 storage server和group，每个storage 在启动后会连接 Tracker，告知自己所属 group 等信息，并保持周期性心跳。tracker根据storage的心跳信息，建立group==>[storage serverlist]的映射表。
2）存储服务器Storage Server
主要提供容量和备份服务；以 group 为单位，每个 group 内可以有多台 storage server，数据互为备份。以group为单位组织存储能方便的进行应用隔离、负载均衡、副本数定制（group内storage server数量即为该group的副本数），缺点是group的容量受单机存储容量的限制，同时当group内有机器坏掉时，数据恢复只能依赖group内地其他机器，使得恢复时间会很长。

5.1.3优缺点
1）优点：
系统无需支持POSIX(可移植操作系统)，降低了系统的复杂度，处理效率更高。
支持在线扩容机制，增强系统的可扩展性。
实现了软RAID，增强系统的并发处理能力及数据容错恢复能力。
支持主从文件，支持自定义扩展名。
主备Tracker服务，增强系统的可用性。
Socket进行通讯，效率会比http更高
适合中小文件存储
提供现成的api，基本可直接使用。
2）缺点：
不支持断点续传，对大文件将是噩梦(FastDFS不适合大文件存储)。
不支持POSIX通用接口访问，通用性较低。
对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略。
同步机制不支持文件正确性校验，降低了系统的可用性。

5.2HDFS

5.2.1概述
Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS是Hadoop平台上两大核心组件之一，Hadoop是大数据技术的一个代表平台，解决的最核心的两个问题，一个是大数据的分布式存储，一个是大数据的分布式处理，HDFS就是来解决海量数据的分布式存储问题。

5.2.2架构
HDFS是基于Master/Slave架构，HDFS 的架构包括三个部分，每个部分有各自清晰的职责划分。HDFS包含3种节点,NameNode (集群的中心节点),DataNode ，secondary NameNode )它是NameNode的一个助手节点。一般NameNode和DataNode部署在不同机器上。
1）NameNode：主要职责是管理整个文件系统的元信息（Metadata），集群启动时候这些信息是存在内存中的。
2）DataNode：真正存储文件块（block）的地方，能定期向NameNode发送心跳信息，汇报本身健康状况及其所有block信息，服务响应 Client 的文件读写的请求，执行文件块的创建、删除和复制。
3）Client：考虑到 HDFS 交互过程的复杂性，所以特地提供了针特定编程语言的Client 以简化使用。Client 的职责能提供面向应用编程语言的一致 API，简化应用编程，改善访问性能。

5.2.3优缺点
1）优点:
高容错性:数据自动保存多个副本,副本丢失后,自动恢复,可靠性同时也实现了加快处理速度,A节点负载高,可读取B节点。
适合批处理:移动计算而非数据,数据位置暴漏给计算框架。
适合大数据处理:甚至PB级数据,百万规模以上文件数量,10k+节点。
可构建在廉价机器上:通过多副本提高可靠性,提供容错和恢复机制。
2）缺点:
低延迟数据访问:比如订单是不适合存储HDFS中的,要求数据毫秒级就要查出来。
HDFS 不适合存储大量的小文件，这里的小文件指小于块大小的文件。,如真有这种需求的话,要对小文件进行压缩。
并发写入、文件随机修改:不适合修改,实际中网盘、云盘内容是不允许修改的,只能删了从新上传,他们都是hadoop做的。

5.3TFS

5.3.1概述
TFS（Taobao File System）是淘宝针对海量非结构化数据存储设计的分布式系统，构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问，通常文件大小不超过1M。

5.3.2架构
采用了HA架构和平滑扩容，保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化了文件的访问流程，一定程度上为TFS提供了良好的读写性能。
TFS是由NameServer和DataServer组成：
1）NameServer管理维护Block和DataServer相关信息，包括DataServer加入、退出、心跳信息，block和DataServer的对应关系建立，解除。
Block是FS将大量的小文件（实际数据文件）合并成为一个大文件，每个Block拥有在集群内唯一的编号（Block Id），Block中的实际数据都存储在DataServer上。
为了容灾，NameServer采用了HA结构，即两台机器互为热备，同时运行，一台为主，一台为备，主机绑定到对外vip，提供服务；当主机器宕机后，迅速将vip绑定至备份NameServer，将其切换为主机，对外提供服务。
2）DataServer服务器一般会有多个独立DataServer进程存在，每个进程负责管理一个挂载点，这个挂载点一般是一个独立磁盘上的文件目录，以降低单个磁盘损坏带来的影响。

5.3.3优缺点
1）优点：
开源,经过淘宝验证是能应对海量的文件存储。
2）缺点：
小于1M的文件
TFS内部是没有任何数据的内存缓冲。

5.4结论
以上几种文件系统都能支持分布式部署，并且能存储海量文件，方便开发者直接进行使用。
1）HDFS
主要是解决并行计算中分布式数据存储的问题，图片管理暂时不涉及。
存储单个文件通常很大，采用分块存储的方式，对于小文件的存储会对NameNode压力很大，而我们存储的照片大小一般为4MB,HDFS不能满足我们的需求。
交互式应用，对于低延迟很难满足，而我们需要快速的加载图片，用于轨迹和图片进行联动，HDFS不能满足我们的需求。
2）TFS
经过淘宝的验证，对于海量文件的管理是很优秀的，能满足我们需求。
适用于小于1MB的文件管理，不能满足我们的需求。
3）FastDFS
适用于4KB < file_size <500MB文件的存储，满足我们的需求。
使用Socket进行通讯，效率会比http更高，适用于以文件为载体的在线服务。
在开发上，不需要二次开发直接可以进行使用，便于我们使用。
综合以上，FastDFS更能满足我们的需求。