tfs文件系统笔记

        上图是tfs官方给出的整体架构图。tfs是一个扁平的文件系统，类似于key-value存储系统，它没有所谓的目录层次结构，所有文件的文件名也不像传统的文件系统（如/home/test/mypicture）这样，而是由tfs文件系统的NameServer给定（这点有点像facebook的haystack系统）。tfs主要是用来处理taobao的图片文件，也就是常见的海量小文件应用。众所周知，小文件带来的最大挑战就是海量的元数据，而一次文件读写操作元数据操作占有的比例往往是相当大的，特别是对于小文件的读写。理想的情况是，将所有的元数据都放到内存中（haystack的论文中已经对这种方案的必要性做了相当充分的说明~）。如何实现将海量小文件的元数据全部cache到内存？很简单，减少元数据呗。这其中就包括精简元数据的大小（不再用标准文件系统vfs中的dentry和inode结构，每个元数据条目将近占用了1K的大小），已经将小文件合并成大文件，减少元数据的总数。道理很简单，具体如何实现呢？可以看看tfs是怎么做的。

        tfs采用了传统的分布式文件系统的架构模式——三方架构，或者说是四方架构。客户端，元数据管理服务器（NameServer），数据管理服务器（DataServer）。此外，还有一个HA组件，我以为它就是所谓的监控模块。

        NameServer算得上是tfs的核心组件吧（个人观点），它负责为文件分配文件名，其实也是指定文件的位置，文件应该放到哪个DataServer上？放到哪个block中？这些都是由NameServer决定的，这其中当然也就包括了所谓的负载均衡技术！tfs应该采用的是动态负载均衡策略，在为一个文件选择DataServer时，它会考虑各个DataServer当前的负载状况，当集群中的负载出现不均衡时，它会控制负载较重的DataServer将部分block迁移到其他负载较轻的DataServer上。此外，tfs还支持集群的动态扩展，当然，说的是数据的扩展。DataServer会定期向NameServer发送心跳信息，所以，当需要向集群中加入一批DataServer时，只需要将NameServer的信息告诉这批DataServer就行了，DataServer向NameServer发送心跳信息，NameServer就能把新增的DataServer加入集群，并且将文件放到这些DataServer上了。

        一个系统需要实际运行，可靠性是最基本的要求。tfs做了几个层面的可靠性保证，首先是集群层面的，可以为一个对外提供服务器的主集群提供一个备份集群，只需要将主集群中的数据同步到备份集群就ok了，这无疑是开销最大的一套机制，但是对于重要的应用来说，确实还是有必要的。另外，NameServer也采用了一主一备的方式，主节点失效了，备份节点能够接替主节点对外服务，同时对外的ip不需要改变。数据的可靠性是通过将一个block保存多份实现的。此外，tfs支持多个进程同时读文件，但是只允许一个进程写文件（不运行多个进程并发写文件的不同部分），tfs的采用了强一致性的写：客户端向NameServer提交写文件请求-->NameServer为文件分配DataServer和block id-->客户端将数据提交给相应的主DataServer-->主DataServer将数据同步到备份的DataServer上-->主DataServer确认数据已经写到备份DataServer上后，再向NameServer提交写完成-->NameServer向主DataServer确认block版本-->主DataServer返回客户端写完成确认信息（有没有觉得很熟悉？这个跟GFS的写流程很相似）。

参考文献：

http://code.taobao.org/p/tfs/wiki/intro/

http://rdc.taobao.com/blog/cs/?p=128#more-128