初涉云计算——从Google三大论文说起

在没接触云计算大数据之前，一听到这个词 就觉得很高大上。现在有机会 参与到一个共同学习的云计算团队中，亲身接触到了云计算。觉得也不那么遥远了。现在我就简单说一下我初涉云计算的一些东西。

说到云计算，自然是离不开Google的三大论文——Bigtable、GFS、MapReduce。初涉云计算就先从这三篇文章讲起。

这里就先说一说GFS——GoogleFileSystem吧

首先，我们应该知道一件事，那就是这么一个系统是用来干什么的，他需要哪些方面的功能去实现，或是需要保证什么。

GFS顾名思义是一种文件系统，它负责了文件的存储，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，并提供容错功能。它可以给大量的用户提供总体性能较高的服务。

既然是一种大型的存储与访问系统，就必须想到组件失效时一种常态的事件，他就需要满足：

1持续的监控；

2错误侦测；

3灾难冗余；

4自动恢复。

同时需要具有灵活性，满足我们对数据的处理修改，支持大数据的存储。

 

简单的了解了这些，看看 GFS的一些组件，架构。先了解一些“名词”

1.master节点

在一个GFS的集群中 只有一个master节点 （当然一个节点并不是对应一个服务器的概念，通常是两台master服务器）。这一个master节点负责的就是对“块”（即Chunk）的一些信息处理并存储，简单的来说就是可以将一些标志性的数据（下面说的元数据）存储起来，方便“块”数据的读写等操作。需要注意的是，客户端操作的数据并不通过master节点，只是通过master节点来获取信息，之后直接根据这信息去从chunk节点那进行操作。

2Chunk

就是上面说的“块”节点，网上有翻译为“块”节点的。一个Chunk的尺寸被设计为64MB，这些Chunk的副本呗保存在Chunk服务器上。选择了这较大的尺寸自然有其理由：

⒈减少客户端和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少很重要。即使对于访问少量数据的随机读操作也可以很方便的为一个规模达几个TB的数据缓存块位置信息。

⒉客户端在一个给定的chunk上很可能执行多个操作，和一个chunk服务器保持较长时间的TCP连接,自然可以减少多余的网络负载，提高效率。

⒊这减少了master上保存的每个Chunk的元数据（metadata）规模，从而使得可以将metadata放在内存中，而不需要再读取时访问硬盘。

不过有利有弊，如此设计不利的一面是：

一个小文件可能只包含一个块，如果很多客户端访问该文件的话，存储这些块的chunk服务器将成为访问的热点。大致就是指同时被多次访问。

3元数据

简单的来说，元数据就是存储Chunk的一些无关数据本身的基本的信息，方便去服务器了解信息，去直接访问相关的服务器。这些“信息”包括了内存的数据结构、Chunk的位置信息、操作日志等。这些都是存储在master的内存中。

 

简单了解之后的，Master节点的一些特殊的操作来管理协调整个文件系统。

服务器通过先访问了master节点来确定Chunk的位置和状态，之后直接去访问chunk服务器区进行读写操作。chunk的信息也是以日志的形式存储在master节点中，一个chunk的失效或是 master与chunk的签订租约都会以日志的方式进行存储。在服务器访问的时候也会把这些信息“反馈”给服务器。此外，建立的垃圾回收和不是删除文件的机制采用“惰性”的回收。

 

上面一开始就讲到了GFS设计时就要求自身具有容错与诊断的能力。GFS就是用自带的工具诊断系统故障。

master 服务器chunk服务器被设计 为数秒内恢复他们的状态（然而并不知道是怎么设计的，，好腻害，，）

对于chunk和master服务器都做了 类似副本处理的方法，这种思路也是正常的思路。不过在这些的基础上还有一种“影子”master服务器，可以在master服务器宕机时 进行只读访问。

 

版权声明：本文为博主原创文章，未经博主允许不得转载。