不同的应用场景，不同的存储架构，不同的性能考量，有什么通用的性能优化手段吗？从我们的实践经验来看，似乎没有，很难有一种方法解决所有的问题，或者说解决了这些问题之后，大家会发现相对专用的文件系统，通用系统总是不能达到你预期的性能，同时也带来了大量开发和调优方面的复杂性。这种情况下，也许我们建立不同的集群解决不同的问题更加高效，这一切都取决于你支撑的业务需求是怎么样的，Google级别集群规模的架构和简单搭建起来的NFS都有其存在的价值。
当然，还是有一些通用的规则的。如果你需要支持的是一个线上服务，那你就要尽量减少一次请求引发的IO数量，IO包括网络及物理磁盘，这些操作引发的性能开销是由物理结构决定，无法用技术手段去优化的。也就是说，这些操作的数量实质上形成了你这个系统的性能天花板，当你设计一个文件系统的架构时，你可以根据这个天花板预估到在不同情况下这套系统的性能表现是怎么样的。
其次，你需要在并发和同步开销之间做出平衡，根据业务的特点选择更适合于你自己的方案，例如从一块磁盘上连续读1MB数据和通过网络并发从10块磁盘上分别读取100KB数据返回给用户，你会选择哪种？那么从一块磁盘上连续读取100MB数据和100并发分别读取读取1MB呢，系统是否有能力支撑这样的并发？绝大部分时候，我们是在做类似的选择。
第三，你需要在成本和性能之间做出平衡，我们可以很方便的使用内存型缓冲来极大地提升系统性能，如果你的系统热点数据集中的话。随着SSD技术的成熟，它可以提供的随机读性能相对传统机械磁盘让人兴奋，随机写性能也有了极大的改善，虽然不像读取提升的那样夸张。如果你的应用读写比例比较高，又可以承受成本，尽量使用SSD吧，虽然当前的成本还是相对昂贵的。InfoQ：从TFS的逻辑架构图来看，NameServer作为中心控制节点，DataServer作为数据节点，这样的架构基于哪些因素或者需求的考虑？
TFS有中心控制节点和数据节点的区分，分别管理两级索引解决数据访问的寻址和传输。相对当前一些开源分布式系统的去中心化趋势，似乎不是非常优秀。但如同对性能的论述一样，每种系统架构都有其存在的价值，中心节点的存在可以保证事务性，我们在某些情况下必须保证写入数据的强一致性，同时在当前的应用规模中也可以非常安全、高效的解决问题。如果有更高的可用性、扩展性需求，我们会在TFS部分中部分体现去中心化的思想。InfoQ：未来TFS的发展计划如何？
TFS未来的开发首先仍然会立足于淘宝网自身的业务需求，同时会照顾开发社区中的需求。我们会逐步支持大文件的存储，也会支持目录和用户权限，同时计划实现按照访问特性分布的分级存储，尽量在性能和成本之间达到一个平衡，还有一些更加精细化的管理功能，例如数据量配额的管理等等。从上面的一些讨论来看，我们不大会做一个通用的分布式文件系统，始终会专注解决当前尚无很好解决方案的问题。InfoQ：您在博客中提到9月份建立TFS开源社区，这对国内社区是个绝佳的学习机会，请问目能否再描述一点开源的细节？
TFS计划在9月底开源，而今年6月底，淘宝网将推出自己的开源社区——code.taobao.org，TFS将完全基于这个开源社区进行开源，大家马上就可以看到。同时已经基本确定使用GPL V2开源版权协议。InfoQ：对于有志于参与到TFS或者目前从事其他类似系统级核心应用的开发人员来说，请问有什么好的建议？
对于有志于参加TFS开发，或者自身已经在从事基础平台、核心系统研发的同行，我相信大家都有相同的感受，在当今计算机体系结构内，我们很难有革命性的技术进展。当前已知的大规模的分布式文件系统都构建在Unix类操作系统之上，或者说绝大部分都构建在Linux之上，这也是从成本方面进行的考量。而各种分布式文件系统架构也大同小异，决定是否成功的关键在于细节，这些细节包括操作系统级别的特化、文件系统级别的特化、实现方面是否足够优秀、足够稳定等等。因此你需要对系统内核有所了解，对文件系统有所了解，比如你知道EXT3的组织方式才可能尽量避免读取一段数据却引发多次磁盘磁头移动的情况，这样你才能最大化的利用好系统资源。而实现的特化可能体现在一个优秀算法的编写、一个高效的通信机制等等，这就要求你有扎实的代码编写能力，对算法和数据结构有颇深的造诣。大家都知道，细节决定成败！