InfoQ：TFS的应用规模达到数百台PC server和PB级数据量，其扩展性如何？架构上是如何保证的？

在TFS中我们将大量的小文件合并成为一个大文件，类似GFS中Chunk的概念，而Chunk的定位信息我们称之为一级索引，而chunk内部具体的文 件定位信息我们称之为二级索引，同时在TFS文件名称中包含这些索引信息，在用户写入一个文件之前，他必须向TFS系统申请一个文件名称。这种方式虽然在 某些情况下显得不像传统文件系统那样灵活，但也给了我们系统更大的可扩展性。我们保证可以中心控制节点的内存可以支撑PB级别的一级索引，而二级索引仅需 要针对单台数据量。这样，我们就避免了数据量膨胀带来的扩容难度。

当存储容量出现不足，我们需要进行系统扩容的时候，可以根据数据增长情况进行规划，任意数量的加入提供相应存储的服务器。而这些新的存储服务器会向 中心控制节点进行报告。而中心控制节点在有数据写入时，将根据已存储容量的百分比、系统当前负载等参数动态地分配写入的服务器。同时，在系统空闲时间段， 中心控制节点也会根据当前的数据分布情况制定数据迁移计划，并逐步完成数据平衡。与此类似，当发生服务器崩溃时，中心控制节点也会进行数据迁移以保证足够 的备份，同时也会进行数据均衡操作。这些操作都是自动进行的，不需要人工干预。

这种方式在1000台以内的集群基本上能够工作良好，如果集群规模更大，中心控制节点可能会出现一些性能瓶颈，届时我们可以使用一个分布式集群来解决，相 应已经比较成熟的技术方案现在已经比较多了。

InfoQ:您在介绍TFS的特点时，多次提到"性能"这个关键词，请问对于一个文件系统来说，性能一般应该考虑哪些因素？目前，提高文件系 统性能的通用方法有哪些？

现在我们可以讨论一下TFS的性能考量的维度了。其实当前每个流行的分布式文件系统都有自己的侧重点，分别针对自己不同的应用场景。

对于离线型的数据分析需求，由于数据总量巨大，底层分布式文件系统更加注重系统的整体吞吐率，为了适应当前流行的map_reduce模型，这一类 的文件系统会将文件切成多份，分而治之。同时和上层的逻辑配合，采用大块顺序写入、读出的方式来提升性能，典型的代表就是Hadoop使用的HDFS。

实际提供线上服务的分布式文件系统中，也根据服务类型的不同而采用差异化的存储方式，例如针对音、视频等相对比较大的文件，可能采用和离线应用相同 的方式将文件切片并发读写访问，从而达到更高的传输速度。由于相同容量下文件数量比较少，甚至有可能完全实现类似传统文件系统的目录、权限等功能，而不会 受到inode的限制。如果面临淘宝相同的海量小文件存储，这种方式就完全无法提供性能的支持了，inode数量的膨胀会很快吃掉大量的昂贵内存，如果要 平衡成本将部分inode放入磁盘，面对基本上完全随机、没有热点的访问又无法保证寻址的效率，我们只能通过减少元数据的方式来解决这个问题。

为什么说我们的TFS面临着完全随机、基本上没有热点的数据访问？在淘宝的数据部署中，TFS前端有两层更加靠近用户的缓存系统来保证用户展示页面 的速度，最终到达TFS的请求大概只有总请求数量的2%左右，随着前端缓冲的效率不断提升，这个比例还会继续下降，我们可以想象一下是否仍然有热点数据存 在。与此同时，淘宝网的业务特点决定了相对于读取请求，写入请求量不在一个数量级上，而修改操作量就更少，这就决定了我们使用进行随机修改、随机写入的方 式来避免顺序写入不进行修改给随机读取带来的成本。

不同的应用场景，不同的存储架构，不同的性能考量，有什么通用的性能优化手段吗？从我们的实践经验来看，似乎没有，很难有一种方法解决所有的问题， 或者说解决了这些问题之后，大家会发现相对专用的文件系统，通用系统总是不能达到你预期的性能，同时也带来了大量开发和调优方面的复杂性。这种情况下，也 许我们建立不同的集群解决不同的问题更加高效，这一切都取决于你支撑的业务需求是怎么样的，Google级别集群规模的架构和简单搭建起来的NFS都有其 存在的价值。

当然，还是有一些通用的规则的。如果你需要支持的是一个线上服务，那你就要尽量减少一次请求引发的IO数量，IO包括网络及物理磁盘，这些操作引发 的性能开销是由物理结构决定，无法用技术手段去优化的。也就是说，这些操作的数量实质上形成了你这个系统的性能天花板，当你设计一个文件系统的架构时，你 可以根据这个天花板预估到在不同情况下这套系统的性能表现是怎么样的。

其次，你需要在并发和同步开销之间做出平衡，根据业务的特点选择更适合于你自己的方案，例如从一块磁盘上连续读1MB数据和通过网络并发从10块磁 盘上分别读取100KB数据返回给用户，你会选择哪种？那么从一块磁盘上连续读取100MB数据和100并发分别读取读取1MB呢，系统是否有能力支撑这 样的并发？绝大部分时候，我们是在做类似的选择。

第三，你需要在成本和性能之间做出平衡，我们可以很方便的使用内存型缓冲来极大地提升系统性能，如果你的系统热点数据集中的话。随着SSD技术的成熟，它 可以提供的随机读性能相对传统机械磁盘让人兴奋，随机写性能也有了极大的改善，虽然不像读取提升的那样夸张。如果你的应用读写比例比较高，又可以承受成 本，尽量使用SSD吧，虽然当前的成本还是相对昂贵的。

InfoQ：从TFS的逻辑架构图来看，NameServer作为中心控制节点，DataServer作为数据节点，这样的架构基于哪些因素 或者需求的考虑？

TFS有中心控制节点和数据节点的区分，分别管理两级索引解决数据访问的寻址和传输。相对当前一些开源分布式系统的去中心化趋 势，似乎不是非常优秀。但如同对性能的论述一样，每种系统架构都有其存在的价值，中心节点的存在可以保证事务性，我们在某些情况下必须保证写入数据的强一 致性，同时在当前的应用规模中也可以非常安全、高效的解决问题。如果有更高的可用性、扩展性需求，我们会在TFS部分中部分体现去中心化的思想。