分布式blog系统 TFS总结

时间:2021-06-06 06:38:06

解决的问题

       文件总量太大  一台服务器无法存放 只能放在网络集群中分节点存放   也就是通过屏蔽网络部分 形成一个“ 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“内部文件名路径”给客户端,他就是指引你应该在哪里写文件。其实就一个文件名编码工作:

  分布式blog系统  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 去找到相应的文件位置 然后读出来。这样读性能应该还是比较高的。

    现在来看看写过程:

    分布式blog系统  TFS总结

      有几个点:写操作对于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了