GFS(Google File System,谷歌文件系统)----(1)文件系统简介
分布式文件系统
-
系统是构建在普通的、廉价的机器上,因此故障是常态而不是意外
-
系统希望存储的是大量的大型文件(单个文件size很大)
-
系统支持两种类型读操作:大量的顺序读取以及小规模的随机读取(large streaming reads and small random reads.)
-
系统的写操作主要是顺序的追加写,而不是覆盖写
-
系统对于大量客户端并发的追加写有大量的优化,以保证写入的高效性与一致性,主要归功于原子操作record append
-
系统更看重的是持续稳定的带宽而不是单次读写的延迟gfs架构
gfs架构:
由三部分组成:gfs master、gfs client、gfs chunkserver。其中,gfs master任意时刻只有一个,而chunkserver和gfs client可能有多个。
一份文件被分为多个固定大小的chunk(默认64m),每个chunk有全局唯一的文件句柄 (一个64位的chunk id),每一份chunk会被复制到多个chunkserver(默认值是3),以此保证可用性与可靠性。chunkserver将chunk当做普通的linux文件存储在本地磁盘上。
gfs master是系统的元数据服务器,维护的元数据包括:命令空间(gfs按层级目录管理文件)、文件到chunk的映射,chunk的位置。其中,前两者是会持久化的,而chunk的位置信息来自于chunkserver的汇报。
gfs master还负责分布式系统的集中调度:chunk lease管理,垃圾回收,chunk迁移等重要的系统控制。master与chunkserver保持常规的心跳,以确定chunkserver的状态。
gfs client是给应用使用的api。gfs client会缓存从gfs master读取的chunk信息(即元数据),尽量减少与gfs master的交互。
读取数据的流程:
-
应用程序调用gfs client提供的接口,表明要读取的文件名、偏移、长度。
-
gfs client将偏移按照规则翻译成chunk序号,发送给master
-
master将chunk id与chunk的副本位置告诉gfs client
-
gfs client向最近的持有副本的chunkserver发出读请求,请求中包含chunk id与范围
-
chunkserver读取相应的文件,然后将文件内容发给gfs client。--------?为什么是chunkserver在读取,而不是client直接读?