主题：【原创】闲话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] 同步的苦恼

极力想把技术类文章写得轻松一点，有趣一点，但是写着写着，感觉表情就严肃下来了。

前面轻松，把人引进来，后面严肃，把细节多讲一点，

保持完整性，奖励坚持看到后面的人。

我自己读了一遍，前面还算轻松，读到“正文”，便有点读不下去的感觉。

1，2，3，4，5，中药铺子开下去，着实有点枯燥。

下一篇开始大批判，来点火药味，不知道会不会增添一点可读性。

坚持写下去不是一个容易的差事。

寄希望于写着写着，或许就写出感觉了。

多谢鼓励。

我觉得已经非常精彩了，1，2，3，4，5看下来，一来开阔了思路，二来知道平时多看论文，将来就会遇到问题多而遇到难题少。

上花，期待下篇。

说真的，的确在单机上觉得很简单的东西到了多服务器的协同工作环境下考虑的东西就完全不一样了。

前阵子同步暂停了一会，痛苦死了，到处查原因，我都好悬没把小黑给扔了。

你开始的引文轻装上阵，让人看起来很轻松，但是从1到5看下来，觉得你埋下了很多伏笔，而且感觉像一张大网一样，越铺越大，我估计到最后很难清理。还不如您先整理一下头绪，这个系列会讲哪些东西，哪些是轻哪些是重，然后做个index，甚至sub-index，然后挨个填？

河兄说得对，给自己铺了个天罗地网，弄得自己害怕了。

诚如河兄所言，的确得理理思路，不能昏天黑地地胡写。