毕业生浅谈Google架构

首先声明：

1、我并非是网站架构师，我刚毕业，只是对网站架构这方面比较感兴趣，于是就把自己学习的心得和大家分享，欢迎大家拍砖，但请稍微拍轻点，毕竟刚毕业的孩子伤不起啊:-)

2、如果喜欢本文的朋友可以以任何形式转载，开心的话留个链接，不开心就算了，因为文中很多资料也是来自网络的。

 

其实不久前我在园子里也分享过一篇有关架构方面的文章各大网站架构总结笔记，感谢大家的点评和支持，让我在大家的讨论中又学到了很多东西。今天，我要和大家一起来谈谈Google的架构，鉴于Google的高不可测和本人的能力有限，所以只能浅谈，园子里牛的人可以在评论中补充哦（好东西拿出来一起分享，让我们共同进步，不要让人家嘲笑我们中国的程序员封闭）。

Google主要以GFS、MapReduce、BigTable这三大平台来支撑其庞大的业务系统，我称他们为Google三剑客，网上也有说是Google的三架马车。

一、GFS（Google File System）

这是Google独特的一个面向大规模数据密集型应用的、可伸缩的分布式文件系统，由于这个文件系统是通过软件调度来实现的，所以Google可以把GFS部署在很多廉价的PC机上，来达到用昂贵服务器一样的效果。

下面是一张Google GFS的架构图：

从上图我们可看到Google的GFS主要由一个master和很多chunkserver组成，master主要是负责维护系统中的名字空间、访问控制信息、从文件到块的映射以及块的当前位置等元素据，并通过心跳信号与chunkserver通信，搜集并保存chunkserver的状态信息。chunkserver主要是用来存储数据块，google把每个数据块的大小设计成64M，至于为什么这么大后面会提到，每个chunk是由master分配的chunk-handle来标识的，为了提高系统的可靠性，每个chunk会被复制3个副本放到不同的chunkserver中。

当然这样的单master设计也会带来单点故障问题和性能瓶颈问题，Google是通过减少client与master的交互来解决的，client均是直接与chunkserver通信，master仅仅提供查询数据块所在的chunkserver以及详细位置。下面是在GFS上查询的一般流程：

1、client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunk index）。
2、给master发送一个包含文件名和块索引的请求。
3、master回应对应的chunk handle和副本的位置（多个副本）。
4、client以文件名和块索引为键缓存这些信息。（handle和副本的位置）。
5、Client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle（chunkserver以chunk handle标识chunk）和块内的一个字节区间。
6、除非缓存的信息不再有效（cache for a limited time）或文件被重新打开，否则以后对同一个块的读操作不再需要client和master间的交互。

不过我还是有疑问，google可以通过减少client与master通信来解决性能瓶颈问题，但单点问题呢，一台master挂掉岂不是完蛋了，总感觉不太放心，可能是我了解不够透彻，不知道哪位朋友能解释一下，谢谢：）

二、MapReduce，Google的分布式并行计算系统

如果上面的GFS解决了Google的海量数据的存储，那这个MapReduce则是解决了如何从这些海量数据中快速计算并获取指定数据的问题。我们知道，Google的每一次搜索都在零点零几秒，能在这么短时间里环游世界一周，这里MapReduce有很大的功劳。

Map即映射，Reduce即规约，由master服务器把map和reduce任务分发到各自worker服务器中运行计算，最后把结果规约合并后返回给用户。这个过程可以由下图来说明。

按照自己的理解，简单对上图加点说明：

1、首先把用户请求的数据文件切割成多份，每一份（即每一个split）被拷贝在集群中不同机器上，然后由集群启动程序中的多份拷贝。

2、master把map和reduce任务交给相对空闲的worker处理，并阻塞等待处理结果。

3、处理map任务的worker接到任务后，把以key/value形式的输入数据传递给map函数进行处理，并将处理结果也以key/value的形式输出，并保存在内存中。

4、上一步内存中的结果是要进行reduce的，于是这些map worker就把这些数据的位置返回给master，这样master知道数据位置就可以继续分配reduce任务，起到了连接map和reduce函数的作用。

5、reduce worker知道这些数据的位置后就去相应位置读取这些数据，并对这些数据按key进行排序。将排序后的数据序列放入reduce函数中进行合并和规约，最后每个reduce任务输出一个结果文件。

6、任务结束，master解除阻塞，唤醒用户。

以上是个人的一些理解，有不对的地方请指出。

三、BigTable，分布式的结构化数据存储系统？

BigTable是基于GFS和MapReduce之上的，那么google既然已经有了GFS，为何还要有BigTable呢（也是我原先的一个疑问）？后来想想这和已经有操作系统文件系统为何还要有SQL SERVER数据库一样的道理，GFS是更底层的文件系统，而BigTable建立在其上面，不仅可以存储结构化的数据，而且可以更好的管理和做出负载均衡决策。

以下是BigTable的架构图：

它完全是一个基于key/value的数据库，和一般的关系型数据库不同，google之所以采用BigTable，因为它在满足需求的同时简化了系统，比如去掉了事务、死锁检测等模块，让系统更高效。更重要的一点是在BigTable中数据是没有格式的，它仅仅是一个个key/value的pairs，用户可以自己去定义数据的格式，这也大大提高了BigTable的灵活性和扩展性。

四、总结

这篇随笔主要是一些总结性的内容，Google架构远远不止这些，不过对于我这个初学者来说，看到这样的架构体系确实让我很激动（可能牛的朋友对这个已经没啥感觉了），就花了差不多一个下午写了这篇文章。我也希望通过自己的努力去更深一步的学习架构方面的知识，也欢迎各位朋友一起探讨。好了，最后我还是希望得到大家的支持，但也欢迎拍砖，不过拍轻点哦，呵呵。