Google File System读后感

[qq_44934901]

从文章中我们知道GFS将整个系统的节点分为三类角色：Client（客户端）、Master（主服务器）和Chunk Server（数据块服务器）。 client（客户端）：Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。应用程序直接调用这些库函数，并与该库链接在一起。该客户端代码主要实现了GFS文件系统的API接口函数、应用程序与Master节点和Chunk服务器的通讯。注意：客户端和Master节点之间通信只获取元数据，所有的数据操作都是由客户端直接和Chunk服务器交互的。 Master（主服务器）：Master是GFS的管理节点，在逻辑上只有一个，它保存系统的元数据，负责整个文件系统的管理，是GFS文件系统中的“大脑”。具体元数据信息包括名字空间、访问控制信息、文件和chunk的映射信息、以及当前chunk的位置信息等。具体操作管理有：chunk的租用管理、孤儿chunk的回收、以及chunk在chunk服务器之间的迁移。 Chunk Server（数据块服务器）:Chunk Server负责具体的存储工作。数据以文件的形式存储在Chunk Server上，Chunk Server的个数可以有多个，它的数目直接决定了GFS的规模。GFS将文件按照固定大小进行分块，默认是64MB，每一块称为一个Chunk（数据块），每个Chunk都有一个对应的索引号（Index）。 1.GFS实现了控制流和数据流的分离。Client和Master之间只有控制流，没有数据流，极大地降低了Master的负载。Client和Chunk Server之间直接传输数据流，同时由于文件被分为多个Chunk进行分布式存储，Client可以同时访问多个Chunk Server，从而使整个系统的IO高度并行，整体性能得到提高。 1.采用中心服务器模式 （1）可以方便的操作Chunk Server（增删改查） （2）Master可以掌握系统内所有Chunk Server的情况，方便进行负载均衡 （3）不存在元数据的一致性问题（因为只有一个中心server，所以云数据也只有一份），当然，此处只是相对而言，我们说的单一master节点的含义是GFS系统中只存在一个逻辑上的Master组件。实际一个逻辑上的Master节点默认包括两台物理机 2.无论是客户端还是Chunk服务器都不需要缓存文件数据 （1）文件操作大部分是流式读写，不存在大量重复的读写，因此即使使用cache对系统性能的提高也不大 （2）Chunk Server上的数据存储在本地文件系统上（Linux File System），若真的出现频繁存取，那么本地文件系统的cache也可以支持 （3）若建立系统cache，那么cache中的数据与Chunk Server中的数据的一致性很难保证 （4）注意是不缓存文件数据，客户端还是会缓存一些查找到的元数据信息 3.Chunk尺寸选的较大, GFS选择64MB 优点 （1）只需要少量和Master节点的通信就可以获取Chunk的位置信息，之后就可以多次进行读写操作 ( 2）选用较大的Chunk尺寸减少了Master节点需要保存的元数据的数量。这就允许我们把元数据全部放到内存中 缺点： （1）因内存碎片造成空间浪费 （2）造成热点问题 4. Master服务器存储3种类型的元数据 Chunk位置信息 注意：Master服务器并不持久化保存哪个chunk服务器存有指定Chunk的副本的信息。Master服务器只是在启动的时候轮询Chunk服务器以获取这些信息。Master服务器能够保证它持有的信息始终是最新的，因为它控制了所有的Chunk位置的分配，而且通过周期性的心跳信息监控Chunk服务器的状态。 5.操作日志 操作日志是干嘛的？保存了关键的元数据变更历史记录。有两点我们需要注意，第一：操作日志是元数据唯一的持久化存储记录。第二：作为判断同步操作顺序的逻辑时间（通过逻辑日志序号作为操作发生的逻辑时间） Master服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。Master服务器在日志增长到一定量时对系统状态做一次快照（CheckPoint）。CheckPoint文件以压缩B-树数据结构存储，可以直接映射到内存。重点：Master服务器使用独立的线程切换到新的日志文件和创建新的checkpoint文件。 6.一致性模型 1.命名空间锁提供了原子性和正确性的保障 2.Master节点的操作日志定义了这些操作在全局的顺序