五千年(敝帚自珍)

主题:【原创】闲话Google集群 [5] 同步的诀窍 -- 邓侃

共:💬11 🌺37
全看分页树展 · 主题
家园 【原创】闲话Google集群 [5] 同步的诀窍

[1] 引子 链接出处

[2] 存在的理由 链接出处

[3] 布局 链接出处

[4] 数据流和控制流的分离 链接出处

[5] 同步的诀窍

上一节中,我们说到,把每个Chunk-server备份小组当作一个单元,每当Crawler向这些小组存放文件时,必须保证每个备份机器中存放的文件同步。同步的最高境界是不仅内容,还有存放位置都必须一模一样。换句话说,每个Chunk-server备份小组中的任何一台机器,都像是小组中其它机器的克隆复制一样。

如何保证同步?

这几天笔者忙着装修房子,想去买几幅画,附庸风雅。北京南四环大红门地区有个集美装修城,这个mall里面有一个外观是西洋新古典主义风格的大楼,名曰“北京卢浮宫”,主营卖画,尤其是油画。那里面西洋古典油画,如“蒙娜丽莎”之类,价格令人吃惊得便宜,几乎可以论斤卖。谁画的呢?

据说货源之一是深圳郊外的“大芬村”。大芬村的特产是复制西洋古典油画,在短短十年间,大芬村从一个名不见经传的小山村,一跃占据了全世界60%的油画市场,年生产销售油画100多万张,加上附加服务,这个小山村一年创汇3000多万美元。譬如“蒙娜丽莎”,在大芬村的出厂价是每张人民币200元,运到欧美市场,每张卖美金2000元,迄今为止,单单“蒙娜丽莎”就累计买了20万张。

想从一堆“蒙娜丽莎”中,挑一张质量比较好的。但是反复比较,发现每张“蒙娜丽莎”彼此极为相似,不仔细看,几乎没有差别。拿我们计算机的术语讲,各个“蒙娜丽莎”备份的同步工作,做得非常好。大芬村在保持同步方面的诀窍是什么?

在开始复制一幅画以前,大芬村画廊的高手们,先研究决定如何制定工序,譬如画风景画,先打底色,然后拿大刷子画背景天空和地面远景,接下来画云朵,以及地面中景,最后是近景等等点睛之笔。通常前几个步骤都让画工们处理。只有关键的地方,才留给高手操刀捉笔。每道工序,都由专人负责,既责任明确,又避免相互干扰。

或许读者会问,这不是与Ford流水线很相似吗?说得对极了。Ford流水线的意义,不仅在于提高生产效率,而且在于保障产品质量的稳定。

闲话说完,现在回头谈Google集群如何处理同步问题。其实,GFS同步的思想方法,与大芬村复制油画,与Ford流水线生产汽车,可以说大同小异。人类的精华思想,或许就那么为数不多的几条,应用到不同领域,做一些缝缝补补,就演变成了汗牛充栋的各种技术。

当Crawler向某个Chunk-server备份小组存放文件时,GFS规定的工序是这样的。

1. Crawler问Master,“这个chunk-server备份小组中,有哪些机器?他们的IP地址分别是什么?谁是这个小组的值班组长?”

所谓值班组长,就是说小组中任何一台机器都有资格做小组长,不存在终身组长。组长由Master任命,任命的原则基本上是,看谁闲得慌,就派谁做组长。如果小组中目前没有在任组长,Master就当即任命一个。任命的方式是颁发给小组长一张委任状(lease)。颁发委任状的细节,Google的论文里没有细谈,不过应该不很复杂。我个人的揣度是这样的,颁发委任状包括两个步骤,

a. Master机器上有一个表格,上面记录着整个集群中有多少个备份小组,每个小组中有哪些机器,每个机器的IP地址等等。在备份小组没有事情可做的时候,是不需要组长的。颁发委任状的时候,Master在表格中组长那一栏,做一个标注,标注的内容是委任状颁发的时间和有效期。

b. Master给荣任组长的机器发个简短的信息,内容主要是委任状颁发的时间和有效期。

2. Master回复Crawler,“你要找的chunk-server小组,包括以下几台机器,它们的IP地址如下。其中,xx是小组长”。

Crawler把这些信息记录下来,以备以后使用。在接下来的时间里,Crawler就不再和Master联系,免得给他添麻烦。

3. Crawler把要存放的文件传到各个chunk-server的内存中去。工序细节如下,

a. Crawler在chunk-server小组中所有机器中,找一个与它最“邻近”的机器。所谓最邻近,可以理解为IP地址最相近。原因是如果两台机器的 IP地址比较相近,那么连接这两台机器之间的网路长度,以及所经过的路由器交换器之类,多半也最短最少。这样一来,在两个邻近的机器之间传递数据,消耗的时间多半也会短一些。

b. Crawler把要存放的文件,传到最近的机器的内存中去。

c. 最近的机器在接收文件数据的同时,把数据传递到小组中最邻近的机器的内存中去。

譬如小组中有3台机器,S1,S2,S3, 其中S1离Crawler最近。S2和S3中,S2离S1更近。Crawler把文件传到S1,文件数据开始传递以后,不一定要等到传递结束,S1就开始向S2传递数据。当S2收到数据后,S2向S3传递。形象一点讲,S1-S2-S3就像一个管道,文件数据从 Crawler源源不断流经这个管道,直到整个文件的数据统统传输完毕。

最近的机器不一定是小组长,譬如离Crawler最近的机器是S1,但是小组长可能是S1,S2或S3中任何一个,譬如S2。

4. 当小组中所有chunk-server机器都收到了完整的文件数据,它们分别向Crawler汇报说,“文件数据已经完整收到”。

这时文件数据并没有写进硬盘,而是缓存在各个chunk-server的内存中。

Crawler向小组长发个请求,请求它下令各个chunk-server把内存中的有关文件,写进硬盘里。

小组长心想,“想写进硬盘的客户多了,不止你crawler一个。要写可以,得先排队”。于是给所有写硬盘的请求排了一个序。

5. 小组长把这个请求序列发给小组中各个chunk-server,说,“我知道在你们的内存中,缓存着以下这些文件。我给它们编了一个序列,你们按这个序列,逐个把文件写进硬盘中”。

6. 当小组中所有chunk-server机器都把内存中缓存的文件,逐个按小组长指定的顺序,写进硬盘以后,它们分别向小组长汇报说,“文件数据已经完整写入硬盘”。

7. 小组长回复crawler,“你请求把文件存入我们小组的chunk-server,恭喜,已经完成,没有发生故障”。或者,回复出现了什么什么故障。

整个工序如下图所示,

点看全图

外链图片需谨慎,可能会被源头改

这个工序,有很多优点,譬如稳妥,回避瓶颈,降低成本等等。但是缺陷也很明显,譬如给client,如crawler的权力过大,效率低等等。下一篇,我们先分析缺陷,然后再谈优点。GFS之所以这么设计,无非是在看重优点的同时,尽可能降低缺点。理想不能圆满实现的时候,只好退而求其次。

关键词(Tags): #Google#cluster#集群

本帖一共被 1 帖 引用 (帖内工具实现)
全看分页树展 · 主题


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河