主题：【原创】闲话Google集群 [4] 数据流和控制流的分 -- 邓侃

[1] 引子 链接出处

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

[3] 布局 链接出处

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

上一节，我们讲到了有备份的集群布局。设置备份的动机是增强系统的稳定性。当一部分机器死机了，只要它们的备份机器还在正常运转，哪怕每个Chunk-server备份小组中，各自只有一台机器苟活，整个系统就不至于全面崩溃。

但是一个文件同时存放在多个机器上，引发了同步的难题。所谓同步，就是保证每个备份机器中存放的文件，不仅内容，还有存放位置都必须一模一样。换句话说，每个Chunk-server备份小组中的任何一台机器，都像是小组中其它机器的克隆复制一样。

同步的问题是个难题，尤其难在存放文件的过程中，万一某一个备份机器突然死机了，该怎么办？要解决这个问题，涉及面比较广。我们先谈谈数据流和控制流的分离问题。

我们在上一节的图3-1中，描绘过一个简单的集群布局。这个布局很傻很天真，缺陷之一是无论存放文件还是读取文件，都必须经过Master。当文件数目大，或者文件尺寸大，或者两者兼而有之时，千军万马都必须经过Master这个独木桥，从而Master不可避免地成为瓶颈。我们在图3-2中，对这个布局做了改进，给Master以及每个Chunk-server都增加了备份，但是这个布局的目的是增强系统的稳定性，但是Master group仍然会成为瓶颈。

有没有办法让Crawler以及Reader，绕开Master，直接与Chunk-server发生联系呢？GFS是怎么处理的？

文件存放：

1. 当网络爬虫Crawler想向GFS存放文件时，它首先与GFS的Master联系，问，"嗨，Master，我要存放这样一个文件，它的URL是~~，它的文件尺寸是~~，请告诉我，应该把它存放在哪一个Chunk-server?"

2. Master答复Crawler，"把文件存在这个Chunk-server，它的IP地址和端口是~~"。

3. Crawler与指定的Chunk-server建立起TCP联系。然后把相应文件的数据发给该Chunk-server。

文件读取：

与文件存放的流程类似，Reader先与GFS Master联系，询问文件存放在哪一个Chunk-server。Master告知目标Chunk-server的IP地址和端口。然后Reader直接与目标Chunk-server联系，读取需要的文件。

图4-1描绘了文件的存放和读取的流程。

这个办法的好处在于，分离了控制流和数据流。

拿文件存放的流程说事儿，步骤一和步骤二的内容是控制流，它发生在Crawler和Master之间。步骤三是数据流，它发生在Crawler和Chunk-server之间。通常情况下，控制流的数据量很小，而数据流包含的数据量很大，所以在图4-1中，我们用细线表示控制流，而用粗线表示数据流。

虽然每次Crawler要存放文件时，必须首先和Master联络，但是因为它们联络的内容仅仅是小数据量的控制流，所以不至于导致Master成为瓶颈。

这个办法有什么缺点？主要有两条。

1. 大文件的存放和读取效率低下。

设想一下，如果我们有一部很长的电影的视频文件，从头到尾对这个文件进行存放和读取，需要很长时间。

改进的办法是把很长的文件剁成若干小段，分别存放在不同的Chunk-sever groups中去。由于每个Chunk-server group只负责一小段文件，存放和读取都不太耗时。当然，这样的做法会带来一些额外工作，1. 在存放的时候，需要分割源文件。2. 在读取的时候，需要把从不同Chunk-server group读到的文件段落，按顺序拼接起来。GFS就是这么做的，在以后讨论负载平衡的章节中，我们再详谈。

2. 不够安全。

由于Master明白地告诉了Crawler，文件应该存放到哪个Chunk-server，这个目标Chunk-server的IP地址以及端口。日积月累，GFS里面很多Chunk-server的IP地址和端口，都会被Crawler知道。幸亏Crawler是Google系统的一部分，是自己人。否则，就有可能被恶意黑客利用，向Google集群发动攻击。

举个例子，我们任何人都可以使用浏览器来访问Google的地图服务。在我们获取Google地图图片的时候，会发现存放中国各省市地图图片的 Chunk-servers，通常是mt0.google.cn，mt1，mt2，还有mt3。设想一下，如果有谁存心和Google过不去，他可以向这四个Chunk-servers同时发动大量请求，索取地图图片。一时间请求太多，会造成造成mt0到mt4几个Chunk-servers忙不过来。

如果恰好在这个时候，有真正的客户想用Google的地图服务，他就不能正常地在短时间内收到mt[0-4]这些Chunk-servers的反馈，就好像mt[0-4]这些Chunk-server死机了一样。这就是所谓DoS(Donial of Service)攻击。

虽然Google集群规模庞大，黑客不可能对整个Google集群发动DoS攻击，但是却有可能集中力量，攻其一点。只要瘫痪了一个或几个Chunk- server groups，就会造成一部分GFS不能正常读写文件，从而有可能造成一部分Google服务不能正常工作。

有没有办法替Google File System解决安全问题？就笔者的知识所限，目前似乎还没有令人满意的解决办法。这也正是作为技术看客的乐趣所在，知道问题在哪里，听各方辩论解决方案，预测未来的技术走势。这就像股民读经济金融新闻，听各路经济学家分析时局，预测股市未来的走势，然后决定是否要买进或者卖出股票。心惊肉跳的时候到了。玩的不就是心跳吗？

这一节，我们讨论了数据流和控制流的分离。在图4-1中，我们把每个Chunk-server备份小组，当作一个单元。似乎当Crawler向这些小组存放文件时，小组中每一个备份机器都能步调一致地存放这些文件。实际情况远没有那么简单，我们下一节，讲专门谈谈向各个备份小组中存放操作时，如何保持同步的问题。

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

有大量前人研究的成果。不知怎地，那段网络爬虫和Master的对话让我想起TCP/IP网络设计中的一些想法。

如果取消Master，那么，可能的一个方法是，每一个节点同时也承担指路的任务，它可能知道，也可能不知道目标节点，但至少知道到达目标节点应该去找谁。同时，请求每经过这样一个节点，就在它发出的客户端或 转发的节点与当前请求到达的节点之间建立起一个连接，直到到达目标节点。在到达目标节点的那一刻，客户端与目标节点之间的“虚电路”也同时宣告建立起来。接下来就是传输了。整个过程就好像虫子在苹果中啃出一条通道一样，因此得名“虫洞理论”。

这对文中提到的安全性也多少有所补偿。

好多年没关注了，可能有些记忆错误，也可能早就过时了吧。

有点类似MeshNetwork的做法。

每个节点保存有限的Routing Table，如果这个节点不知道最终目标，它就把用户介绍给Routing Table中某一个或几个最有可能知道最终目标的节点。

也有点像Milgram关于六度空间人链传递的试验。链接出处

但是缺陷是，路由的时间难以控制。

所以，以小人之心度Googler之腹，GFS的设计者们或许会想，“还是设一个Master方便，更何况Master还有其它用途”。下文中会一一提及Master的其它用途。

去年我有一个项目，原来考虑使用gfs，后来放弃了，原因两个

1、系统运行中产生大量的小数据文件，而且实时性要求很高；hadoop默认的文件块是64m，小了性能不行；大了实时性不能满足要求；

2、namdenode是一个有状态的单点，无法实时备份。

后来的解决方法是将中间文件放在存储上，但是硬件成本太高，而且睡着系统的运行，硬盘空间的需求越来越大。

请教有什么更好的思路么？

不知道这两年流行的Megaupload和RapidShare是不是也是采用GFS？

GFS的实时性的确不是特别好，今后在分析如何分配文件存放方式时会详细解释。

用GFS存放文件，目的是解决海量规模问题，你的理解正确。用GFS来处理背景操作，如更新Inverted index之类，是很有效的。但是用作Google map线上服务，未必非常合适。

对于强调实时性的线上服务，最好的办法是把文件缓存在内存里，而不是硬盘中。不过，GFS的论文中没有讲，找遍Google的论文，都没有读到他们是如何解决内存集群的。而我猜测，这才是Google集群最关键的地方。

等我讲完GFS，以及Bigtable以后，或许会探讨Google Cache Cluster。不过，那已经不是Google论文里的内容，而是我等党外人士，为党献计了。当然，更有可能，党内人士看了后，会冷笑一声，说，“你想到的，我们早就做了。你没想到的，我们也做了。”

Google的牛人很多，比我等高超不奇怪。先给自己找个体面下台的梯子，呵呵。

听说过，但是没有深究，所以不敢在河里乱嚷嚷。

有哪位爷知情，给大伙儿说几句如何?

搜索引擎都是按照一定的hash算法存储数据的，也就是说虽然是同样是中国的数据（甚至一个城市的数据）会被hash到不同的机器上。这样做就可以一定程度上避免你说的问题，还有一个好处就是当美国网民查询时候，中国网民在睡觉。

另外dos防御和GFS没有关系，到了GFS这层都是合法的请求了。在前端dos攻击就应该被过滤掉。

如果有兴趣，你大可以dos google一把，你会看到要你输入验证码的页面。

同意，在后面讲到负载平衡的时候，会详细说。

GFS是不是御敌于国门外，GFS的论文里面没有讲，因为安全问题不是GFS本身架构设计的问题，这个你说的对。

至于Google集群如何抵御DoS等等攻击，我也不太熟悉。似乎没有公开的文献可以读。不知道谁能详细谈谈，非常有意思的题目。

在用户PC上放个COOKIE就行了。如果检测到某台PC发送大量请求就对其进行验证码限制。

现在的ddos都是同时用大量的肉鸡发起攻击

如果肉鸡们查的东西都一样，而且没有意义，直接就封了这个词

还是有缺点，cache key->value形式的小数据比较方便，大一点的文件不好cache。

顺便说一下，看了看memcached的源码，发现写得还真不错阿，呵呵。