主题：【原创】闲话Google集群 [6] 同步的苦恼 -- 邓侃

[1] 引子

[2] 存在的理由

[3] 布局

[4] 数据流和控制流的分离

[5] 同步的诀窍

[6] 同步的苦恼

前些时间，有人拿了本国内被禁的“晚年周恩来”，问我要不要读，我回绝了。周公的传记我通常不读，原因是周公太完美了，他是神。神可以被崇拜，但是不可以用来怡情。关于小林元帅的文章，我几乎从不放过，即便在很忙的时候，熬夜也读。小林从大雄走向大奸，不仅褒贬参半，而且争论颇热闹。

做学问也类似。教科书适合催眠，只有俯首帖耳消化吸收的被动，没有激扬文字指点江山的豪情，不打瞌睡不符合人性。读论文有趣得多，趣味在于多数论文只是一家之言。他可以宣扬他的观点，你可以指指点点评头论足，甚至可以另立山头同台打擂。

有关Google集群的论文比较有趣，原因有三，1. Google集群是当今世界规模最大，实际运行效果最好的集群；2. Google的同志们年轻朴实，行文朴实，有啥说啥，不拿一大堆数学公式或者半文不古的术语来忽悠人；3. Google集群并不十全十美，我们大快朵颐消化吸收的时候，不必俯首帖耳，吃饱喝足了，抹抹嘴，说，姜还可以多放些，葱最好打结，这样汤的味道会更厚实。

前一节讲到，当client向某个Chunk-server备份小组存放文件时，GFS规定的工序分7步。看似复杂，其实可以概括为三件事，1. Client向Master打听chunk-server小组中每个机器的地址，以及谁是小组长，2. Client把数据推送给地理距离最近的机器，然后逐步线性扩散到小组中所有机器，3. 小组长决定写入硬盘的顺序后，依次把内存中的数据写入硬盘。

这个工序好不好？好！但是我们今天偏来抬抬杠。抬杠这个词听起来有点情绪化，更贴切的说法是质疑，目的是探究有没有可能进一步改善同步的工序。

1. Client的权力是否过大？

a. Client（如Crawler）知道chunk-server中所有机器的地址，以及当前小组长是谁。这样chunk-server小组的隐私就暴露在client面前。

有人或许会说，反正client是集群内部自己人，不会有恶意攻击的情况发生，所以隐私暴露就暴露吧。这个想法过于乐观了，Google的集群有多达上百万台机器，林子大了什么鸟都有。万一某一台机器被恶意挟持了，或者万一有某个应用程序出了bug，无防范的众多chunk-server就倒霉了。

譬如client方面一个循环语句的中止条件写错，导致client不停地给chunk-server重复地发送相同数据，就像BBS里无聊的人刷屏一样，很快chunk-server的内存将会被灌满。这个时候chunk-server能做什么？要么内存被灌满以后，拒绝随后到达的新数据。如果这样，其它无辜正直的clients就不能顺利地向chunk-server传送数据了。要么，另外一种可能是，chunk-server循环使用内存，新来的数据将覆盖以往的数据。如果发飙的client传送数据的速度很快，那么可能的后果是chunk-server的大部分内存空间，被来自发飙client 的垃圾数据充斥。两种后果都很糟糕。

b. 在关键的第三步，client自主决定先给小组中那一台机器传送数据。Client想什么时候传送数据，就什么时候传送，它不考虑chunk-server的内存是否即将被占满，它也不考虑chunk-server网络带宽是否已经严重堵塞。

在第四步，又是client给小组长下令，把内存里的数据写入硬盘。当小组中各个chunk-server都已经接受到了数据，存放在内存中以后，理应尽快写入硬盘。但是什么时候开始写，决定权又是在这个我行我素的client手中。如果client正在忙着处理其它事情，它就顾不得下令写入硬盘，尽管下这个指令不费吹灰之力。造成的后果是，chunk-server内存中的数据不能及时写入硬盘。内存一旦被占满，后续的数据就不能被顺利发送到 chunk-server，或者先前到达的数据被覆盖。

所以，client掌握了太多的主动权，隐患很多。

c. Client缓存chunk-server中所有机器的地址，以及当前小组长是谁。万一这些信息发生改变，而client没有及时更新，会造成什么后果？

它自说自话地把数据发送给最邻近的chunk-server，进而扩散到小组中其它chunk-servers。然后和自己心目中的小组长联系，说，“所有数据都到位了，您老可以下令让各个chunk-server写进硬盘了”。没想到，小组长回信说，“俺已经卸任了”。得，client只好再找 master，问，“新任小组长是谁啊？”，等等。

如果只是换了一任小组长，那么后果还不算太严重，浪费一点时间而已。如果小组成员中，更换了机器。问题就大了。譬如，client的缓存里说，这个小组有 S1，S2和S3三台chunk-servers，S1和S2都已经回信说传送的数据已经存放在各自的内存中了，可是S3一直没有回音。Client就 re-try，一遍又一遍，无异于灌水。

关于Client缓存过期信息，GFS论文里很坦诚地承认了，这种可能性的确存在，参见第2.7.1节倒数第二段。但是论文辩解说，缓存的时间是有限的，所以这个可能性虽然存在，但是频率不会很高。如果真得束手无策，只能祈求错误出现的频率不高，但是有没有彻底杜绝错误的办法呢？

2. 小组长的权力是否过小？

干部的任命从来就不是一件小事，委任chunk-server小组长也同理。Master在决定谁最适合被任命为小组长时，需要考察小组中所有成员的工作负荷，健康情况等等。虽说这个工作的成本不大，但毕竟是有成本的。更麻烦的在于，委任状是有有效期的，有效期一过，需要注销，或者续约。

审查通过，又续了约，总算稳住了名号，圈里圈外总算有了点人望，却发现却是一个闲职。好生无趣。小组长的职责是什么？无非是第四步时，client递过来个条子，说，“时候差不多了，该把内存里的数据写进硬盘里去了”。小组长便列了个先后次序的单子，让各个chunk-server分头去写。说来说去，稍微有点技术含量的活儿，无非是决定优先顺序。其实也没什么技术含量，多半是重复先来先服务的老把戏。

前面说了，client的权力太大，能不能让闲置的小组长分点权力？皇帝要稳固皇位，无非是在外臣和内戚之间搞平衡。太祖为什么要启用江青和毛远新？无非是外臣势力过大，需要启用内戚来制约而已。

小组长可以做哪些事情？如果GFS让我出主意，我可能会这么建议，

1. 小组长决定哪一个chunk-server去client那里取数据，什么时候去取，而不是由client来决定。

Client没必要，也不应该知道小组中所有chunk-server的地址。由chunk-server主动向client索取要存放的数据，而不允许client随意灌水。

2. 小组长决定chunk-server们什么时候把内存里的数据写进硬盘，而不由clent来决定。

自家内部的事情，岂容外人干涉。

明摆着是夺权。

Client接触的应当是Master和小组长。就像是顾客来到银行，接待他的是大堂经理。顾客对大堂经理说，“我这里有一笔钱想存入贵行”。经理把顾客引到某个柜台，说，“这位服务生负责接待您”。顾客把钱交给服务生，服务生完成所有的储蓄手续。

如果大堂经理递给顾客一张名单，说，“你看，这是我行所有与储蓄业务有关的部门和工作人员，您自主决定怎么存”。估计大多数顾客脸色不会好看。如果某位顾客开怀地笑了，保不定银行将来会失窃。

夺权有理，这个理，并不在于容不下小组长游手好闲，而是在于强调内外有别。

待续