主题：【原创】闲话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之所以这么设计，无非是在看重优点的同时，尽可能降低缺点。理想不能圆满实现的时候，只好退而求其次。

• 【原创】闲话Google集群 [6] 同步的苦恼