解决的问题

　　　　　　 文件总量太大  一台服务器无法存放 只能放在网络集群中分节点存放   也就是通过屏蔽网络部分 形成一个“ one big CPU” 和 “one big disk” 。Client只需要向这个CPU去做read/write/mofity操作即可。但是对于业务的不同，也无法去满足满足通性，根据业务的不同设计不同的系统 效率比较高【个人见解】

　　TFS个人理解

　　　　　　　因为在gfs的架构 影响后面的分布式系统的设计 中心节点和从节点 因为在做存储文件这块 gfs能够承受google业务 所以对于一般公司 只要按照这种架构设计和实现好 应该都能很好满足业务需求。

现在看看具体的TFS。先看下一个业务需求：有200亿图片要存入到一个系统中，系统能够很快的定为出来图片文件在哪里，并且可以支持读写操作。图片元信息假设64字节，200亿*64>1Tb 这个元信息都可以把一个主机磁盘塞爆，另外如果即时元信息放进去了 metadata不能把所有文件目录下的数据都缓存到内存中，查询很可能导致了要读3次磁盘，这点效率很低。看看TFS如何设计的：

　　     文件系统所具备的基本信息

　　　　　　　　 要通过一个文件系统寻找到相应的文件 需要知道文件的目录【延伸到文件在哪里】以及文件大小【要读多少个块】，OS才能从这个系统中读取出来。

　　　　核心机制　　

　　　　多个小文件共用一个物理文件。也就是通过调控这个物理文件大小 可以单台机子可以存放所有小文件的meta信息 使得这个不在成为瓶颈。所以得讨论出具体的TFS怎么做到这个共用？

　　　物理文件我定义成Block 1~Block n. 大小为M兆。

　　　图片文件名为picname,大小为pKB.TFS唯一64位编号为id.

　　　 tfs客户端通过请求NameServer写入一个小文件picname,NameServer分配一个TFS“内部文件名路径”给客户端，他就是指引你应该在哪里写文件。其实就一个文件名编码工作：

　　　　含有block id和file sequence id。核心东东，其实在master里维护的都是meta information。这样master通过调控block大小 来调控整个TFS集群所能支持的一个文件数量。屏蔽内部写的情况，如果TFS写入成功，这个返回出来的这个信息要和一般的文件对应呢？需要有一个数据库记录这2者之间的关系。所以说还得要有数据库来记录这些文件所在的位置。kv系统在合适不过。

　　　　现在来看看我们的master里存储了啥： 现在对于master而言 就是一个一个block信息块，可以map<blockid,metea>来存储查找元信息。这样master的内存不足部分解决了。对于client无论是读还是写 都要都只要请求master的block id和offset。如果客户端缓存的话，就直接去相应的DataServer找。所以呢 这点设计还是非常好。

　　　　读过程就非常明显了：tfs_file  ----------->block_id---->meta信息----> block id和file offset 去找到相应的文件位置 然后读出来。这样读性能应该还是比较高的。

　　　　现在来看看写过程：

　　　　　　有几个点：写操作对于tfs而言 所一个单线程模型结构，所有的写操作都会排队 一个接着一个的写，不能并发写。这样设计他应该是认为写毕竟是少数时候 而多数时候都是读 所以慢没有很大的影响。实现起来会比较方便。 这里的DataServer(master)就用于和nameserver交流控制信息。Nameserver交互比较多，会拖慢nameserver速度。然后复制的时候的策略就是master和dataserver replication。等所有步骤都完成了才会向客户端发送写成功。中间一个操作挂了 就重新写。代价还是蛮高的。

　　　　　TFS容错机制 容灾  扩容

　　　　 一个集群机里 如果DATAserver容量不够了 自动扩容按理来说也是非常合理的事情，同样 一台主机节点挂了，他的复制品按理来说应该会把内容写入到其他的主机上，通过master的寻找自动处理这种机制。这些内容是靠maseter来做的，同样master和备用master应该是同一复制品。master挂了 也可以自动切换。这点还是非常重要的，但比较简单，有一点主master和备用master应该采用同步机制，不然可能出现不一致性现象。

　　　　　　master按理来说要维护dataserver所有的心跳信息，如果没有在指定的时间发回信息，我们怎么办？启用数据迁移机制， 所以说为了寻找这个主机的block id，应该维护这样的map<dataserver,block_id>的操作吧，寻找起来会快速很多！然后根据新的整体信息每个节点的信息和容量来决定分配新的DataServer。

　　　　　　如果整个TFS集群挂了 应该采用双写双机房更安全，不过会比较烧钱吧 嘿嘿！

　　另外的点　　　　

　　另外1：数据而言，有可能读取非常不均匀，多数客户端同时请求读同一个block_id怎么办？ 其实缓存还是必须得做的，我指得是文件缓存，这样可以减低了效率，当然本身数据就没有任何的冷热点，那样为了维护缓存会耗费的更多时间，应用数据应该都具有一定的冷热性吧。嘿嘿 只要不要突然请入了很多无关数据把缓存池被污染了 那就比较麻烦了 那是缓存 以后有机会在讨论这些问题。

　　　2: 读一个64M的文件的某个offset起的n个byte，这个问题其实对TFS读应该是一个比较大的性能损失，要调用lseek() 然后read（） 或者直接全部read到内存里[那更不可靠呀]。如果能很好的解决这个问题 read性能还是很高的。不知道tfs是怎么做这点的 以后可以好好看看源码研究下。

　　　　OVER了

分布式blog系统 TFS总结