TFS与其他分布式存储系统的对比分析

TFS与其他分布式存储系统的对比分析

 

1　概述

TFS（Taobao File System），作为目前淘宝内部使用并开源的分布式文件系统，为淘宝提供海量小文件存储以及其他一些功能，被广泛地应用在淘宝各项应用中。其他分布式存储系统，这里主要指的是最近我通过读论文以及网络上的技术文档和分享所了解到的一些大公司所采用的存储系统，其中包括Google的GFS，BigTable（BT），Amazon的Dynamo以及Facebook的Cassandra。当然，市场上还存在着其他分布式存储系统以及相应的产品。而前面提到的这些产品，正是这些分布式存储系统的优秀代表。

在这五个分布式存储系统中，从数据是否结构化的角度划分，TFS、GFS和Dynamo均属于非结构化的存储系统，而剩下的BT和Cassandra则是典型的结构化Key-Value存储系统。由于它们和传统的关系数据库存储系统的差别，我们一般称之为NOSQL存储系统。另一方面，从系统的整体架构上来划分，TFS和GFS以及BT均属于星型（因为类似于网络中的星型拓扑设计）的架构设计，也就是采用中心服务节点控制数据服务节点的方式来对客户提供服务的。而剩下的Dynamo和Cassandra则是属于去中心化的P2P架构设计。正是由于它们在整体架构设计上的区别，很多分布式系统中所涉及的技术在实现上也存在着比较大的差异。

下面，我将从设计需求，具体架构，技术实现细节等这几方面对上述这些存储系统进行对比阐述。由于本人在分布式系统以及存储系统上刚刚起步，认识尚浅，水平有限，如有错误和认识不足的地方，请大家悉心指教，不胜感激。

2　设计需求

我们都知道，需求分析在软件工程中所处的地位是举足轻重的，如果需求没有分析到位，在软件的实施过程中往往会出现返工的现象，那样就会给软件的实施方造成巨大的损失，甚至是无法弥补的。对于分布式存储系统来说，我认为真正的需求包括两个方面，一个是功能上的需求，另一个则是性能上的需求。不管是功能上的需求还是性能上的需求，都有可能对系统的整个实施产生影响。

2.1　功能需求分析

从功能需求这一方面来看，TFS最初是为了满足淘宝内部对于小文件的存储需要而设计的。后面又加入了对大文件存储的支持，再到后来，又加入了对于各种特定应用的自定义文件名的支持，在读写方面，需要满足大规模的随机读写。这些功能上的需求，TFS在设计的最初应该是有所考虑的。至于其他几个存储系统，据我所知，GFS最初的设计是为了支持大文件的存储，并且在读方面需要满足大规模的流式读和小规模的随机读，在写方面需要满足大规模的追加写和小规模的随机写，BT则需要在Google的各项应用中均能灵活表现，Dynamo是为了支持Amazon的购物车而设计的，并且要求时刻不能停写服务，而Cassandra最初是为了解决收件箱搜索的存储需要而设计的。

2.2　性能需求分析

再从性能需求这一方面看，这几个分布式存储系统的一个最主要的共同点就是可扩展性（即伸缩性）比较好，这也是目前几乎所有的分布式存储系统所支持的特性。另一方面，可用性也是大部分分布式存储系统所支持的特性。如果一个分布式系统在读写性能上和单机的相差不大，那么这个分布式系统的设计无疑是失败的，或者说设计是有问题的。同时，很多分布式存储系统都是布置在普通的机器上的，某一台机器的不可用对于整个系统来说是很正常的事情，于是保证系统的可靠性也是几乎所有分布式存储系统所要考虑的问题。在可靠性的设计中，会涉及到包括复本（replication），负载均衡，数据一致性等很多复杂的问题，这些会在第四部分进行详细的分析。

另外，在分布式系统中存在一个有名的理论，即CAP理论。代表含义如下：

Consistency（一致性）：任何一个读操作总是能读到之前完成的写操作结果。

Availability（可用性）：每一个操作总是能够在确定的时间内返回。

Tolerance of network Partition（分区容忍性）：在出现网络分区的情况下，仍然能够满足一致性和可用性。

并且这个理论认为，CAP三者无法同时满足。事实上，对于分布式系统来说，CAP理论其实是在给我们设计的时候提供了一个思路，那就是既然鱼与熊掌不可兼得，想要C和A，往往就需要牺牲P，那么如何在这三者之间做一个平衡考虑呢？针对不同的应用需求和功能需求，就需要设计不同的系统。

对于星型的系统，我们可以将CAP理论的定义做出适当的调整如下^[1]：

一致性：读操作总是能读取到之前完成的写操作结果，且不需要依赖于操作合并；

可用性：读写操作总是能够在很短的时间内返回，即使某台机器发生了故障，也能够通过其它副本正常执行，而不需要等到机器重启或者机器上的服务分配给其它机器以后才能成功；

分区可容忍性：能够处理机器宕机，机房停电或者出现机房之间网络故障等异常情况；

而对于P2P类型的系统，在一致性方面需要依赖于操作的合并，但它们在P方面是做的比较好的。因此，我们认为大部分星型的系统选择的是CA，而P2P的系统选择了AP。但并不是所有的系统都这么做的，关键还在于平衡把握这三者对应用的影响。

3　具体架构

无疑，在系统的架构和很多细节的设计上，TFS参考了GFS的设计思路。所以在描述TFS的具体架构之前，我们可以先来看看GFS的具体架构。

3.1　 GFS架构

一个GFS集群^[2]包括一个Master节点（这里一般是两台物理机器，外面来看仅仅是一个逻辑节点）和多个ChunkServer节点以及多个客户端访问。存储在GFS中的文件都被分割成固定大小（GFS中是64MB）的Chunk，并且给每一个Chunk分配一个不变的，全球唯一的64位的Chunk 标识。ChunkServer节点以Linux文件的形式将Chunk保存在本地磁盘中。所有的机器均是普通的Linux机器并运行着用户级别（user-level）的进程。下面我将从Master节点，ChunkServer节点，客户端以及缓存这四个方面描述下GFS的设计架构。

Master节点的主要功能是管理文件系统的所有元数据（为了找到真实数据所需要的数据，类似于Linux文件系统中的inode），并且这些元数据均是放在内存中进行管理的。这里的元数据包括Chunk和文件的名字空间，访问控制信息（是否可读写等权限），