其他分享
首页 > 其他分享> > system desing 系统设计(三): 分布式文件系统distributed file system设计原理

system desing 系统设计(三): 分布式文件系统distributed file system设计原理

作者:互联网

   1、众所周知,数据要想永久保存,肯定是要放磁盘的啦!磁盘和内存不一样,内存最小的存储单位是byte,1 byte = 8bit;但是磁盘不一样了,最小存储单位是 sector, 1 sector = 512byte!而在磁盘上,数据都是以文件file的形式存储的。假如文件大小是1kb,那就需要在磁盘上找2个sector来存放!那么问题来了,现在磁盘的容量都是TB级别的,每个sector的大小是512byte,那么磁盘上有billion级别的sector,读取的时候怎么知道这2个sector的位置了?所以肯定是要在磁盘上找个地方存文件sector位置的。除此以外,文件自生还有很多属性要存储,比如文件名、大小、创建时间、创建用户等(大家打开文件夹,看到文件list时就能看到这些文件属性了),如下图: 

         

         这些属性统称为metadata(当然也包括了文件数据本身存放在sector的位置);因为对mestadata的访问频率远高于文件内容本身,所以metadata一般会和文件内容数据分开存放,比如刚开机时,就会把所有文件的metada读到内存,后续直接从内存读metadata,然后从里面找到这2个sector在磁盘为位置,进而从磁盘把文件内容读出来!整个流程就是这样的,但问题很明显:sector只有512byte,导致磁盘sector的数量是billion级别的,光是存储sector的位置就要耗费GB级别的空间,该怎么优化了?

  既然sector的颗粒度太小,导致管理成本高,那就提升磁盘存储的颗粒度呗!这里一次性把8个sector看成整体,8*512byte = 4096byte =4kb,这里定义为block!所以现在metadata的结构展示如下:

       

     block的大小和memory page的大小一样了,但如果按照block划分空间,产生的数据块还是很多,需要存储block offset的耗费还是很大。比如存储高清、蓝光电影,需要耗费上百GB的磁盘,如果按照4kb的block来计算,需要26 milliom个的block来存储,要记录这么多block offset,这个文件的mestadata该多大啊!为了减少metadata的大小,只能进一步提升颗粒度了,这里继续把最小存储单元的大小设置为64MB,称之为chunk!此时如果再存储100GB的文件,只需要 1600个chunk了,极大减轻了metadata的存储压力!图示如下:

          

    此时的文件存储,还仅限于单机!如果现在要存10PB数据,单机肯定是存不下的,怎么在集群上存储这些数据了?

    2、单机存不下,肯定就要考虑cluster集群的啦!一个集群,少则几个node,多则几千甚至数万nodes,这么多nodes,该怎么去管理和运维了?

  (1)集群的管理和组织方式有两种:P2P和master-slave模式!

     确定了master-slave模式,接着该讨论master和slave的功能定位了!从名字就能看出来,master是管理节点,slave是具体干活的,所以很自然而然的就能想到: master负责管理和分配slave,slave负责具体的存储数据!图示如下:

       

       master存放了大文件的metadata,最重要的就是index了:记录了文件chunk在哪个slave的哪个offset!为了更加灵活,slave可以自行决定文件存放在哪个chunk!

    经过上述铺垫,distributed file system写入流程就容易理解了,如下:

       

    读的过程类似:

      

  (2)上面解决了数据分布式存储问题,可万一slave宕机了怎么办?slave的磁盘坏了怎么办?一个大型集群有数千甚至上万节点,有少量节点宕机正常,怎么才能确保数据不丢失了?

       replica 副本的存储过程如下:

  

 

     存好后读的时候就简单了:3个slave随便找个就行啦!不过有一点要注意:数据存放后会随同一起存放checksum(可以是简单粗暴地把数据相加,也可以是取MD5等)!读取数据时也会检查checksum,如果不一致,说明数据损坏了,需要修复,最直接的办法就是找master帮忙,提供另外两副本的slave,然后从这两个slave取数据修复,流程如下:

  

 

       读数据时,如果连slave整机都宕机了,直接选取另外两个读取,流程如下:

       

 

   大型集群,master为了随时随地都能了解到slave的情况,以便后续的任务分配,需要slave每隔固定的时间给master发送消息,以告诉master自己仍然live,这种机制叫heartbeat!

        

 总结:

1、分布式文件系统,核心就是把文件拆分成chunk大小,合理地存放在不同的节点!

2、集群中master负责分配slave节点、记录文件在slave的chunk;slave负责存放数据

3、数据损坏后,slave会找master提供另外2副本的位置,然后通过这2副本恢复

 

参考:

1、https://www.bilibili.com/video/BV1Za411Y7rz?p=55&vd_source=241a5bcb1c13e6828e519dd1f78f35b2   GFS设计

标签:sector,文件,存储,slave,distributed,system,master,file,磁盘
来源: https://www.cnblogs.com/theseventhson/p/16589737.html