五千年(敝帚自珍)

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

共:💬33 🌺52
分页树展主题 · 全看首页 上页
/ 3
下页 末页
  • 家园 【原创】闲话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和小组长。就像是顾客来到银行,接待他的是大堂经理。顾客对大堂经理说,“我这里有一笔钱想存入贵行”。经理把顾客引到某个柜台,说,“这位服务生负责接待您”。顾客把钱交给服务生,服务生完成所有的储蓄手续。

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

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

    待续

    关键词(Tags): #Google#cluster#集群
    • 家园 这个系列还继续吗?
      • 家园 不准备写了

        这个话题太专业,读者寥寥,写手也就没了精神,呵呵

        • 家园 还是写吧,帖子不热闹只是说明了解的人不多。

          并不意味着帖子本身没有价值。

          • 家园 原因

            上次晋见铁舵手。舵手下达了一个指令,要我帮忙把IT版炒热。

            想来想去,要炒热人气,还是得走群众路线。Google clustering的读者群太少,把有限的精力投入这个话题,与舵手的指示不太吻合。

            所以就去写那个硅谷野史了。

            年底了,事情多。你看那个野史我也顾不过来了,罪过罪过。打算本周末把自己关在家里,猛挤一通牙膏。

            • 原因
              家园 我也觉得,写技术贴不好

              平时侃侃说不定还brain storm有火花。写出来就大多数沉默了。真的要搞点火的有技术含量的东西,论坛大概不太适合。有时候真想到个东西,兴奋地发上来,却可能论坛没人。等过了兴奋劲,自己的脑瓜都凉了

            • 原因
              家园 不知道铁手对流量做过统计没有?

              如果国内访客居多,可能中关村野史更招人待见。

        • 家园 真是河里iter一大损失阿,可惜可惜,我可是逐篇上花的。

          等手头事情做完,我又要开始捣鼓hadoop了,呵呵。

        • 家园 遗憾

          兄台文章一贯深入浅出,发人深省,俺虽然下河时日尚浅,兄台的文章却是一直在追捧。

          文后大家的讨论也大有裨益,撼!

        • 家园 呵呵,先留着坑

          什么时候有了想法回来再填也不迟阿,正因为专业才需要您给大家科普阿。

          虽然当时看这个标题我就没敢进来,可是也许多看几遍也就看懂了,有求知欲总是好事。

        • 家园 别呀,我一直在默默地读你的文章

          佩服和学习

    • 家园 占坑

      这东西真难讲

      还是找多些有经验的人来做人工干预

      就像一台大型手术那样,各个专门领域的医生们轮流上场,护士们也干不少活。

    • 家园 借问老兄一个问题:

      Gmail的邮件标签在存储和检索上是怎么实现的?老兄可有研究?

分页树展主题 · 全看首页 上页
/ 3
下页 末页


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

Copyright © cchere 西西河