- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】闲话Google集群 [3] 布局 -- 邓侃
[1] 引子 链接出处
[2] 存在的理由 链接出处
[3] 布局
系统架构设计，以我个人体会，可以分为几个方面，机器和网络布局，数据流组织，控制流组织，负载均衡，线程规划，数据同步，数据恢复，系统安全和系统健康状态诊断等等。成为架构设计高手很难，但是入门并不那么困难。
我们不妨以Google File System（GFS）作为一个案例，逐一解剖这个系统的架构设计的各个方面。在分析完GFS以后，再解剖分析Google的分布式数据库，Bigtable的架构设计。如此分析多个系统的架构后，或许大家对系统架构设计就会有一个比较清晰的了解，我们的讨论也就会更深入，更有趣。
为什么要实现Google File System？最根本的原因，是因为要存放的数据的规模太大，以至于任何一台PC放不下，所以需要一个集群的PC来完成这个任务。数据的规模太大，也许是因为数据文件的数目很多，也有可能是因为单个文件的尺寸太大，也有可能是不仅单个文件的尺寸大，而且大尺寸的文件数目多。
设想一下，如果要存放的数据的规模是5000G，而一台PC的硬盘空间是500G，那么我们可以把数据分成十份，分别存放在不同的PC上。但是问题是如果我们要读取某个文件时，我们怎么知道这个文件在哪个PC里呢？有两个办法，
1. 逐个访问每个PC。但是这样的效率会比较差。
2. 另外再设一个PC，这个PC里存放着一个目录，专门记录哪些PC存放了哪些文件。这样的做法，好处是效率高，缺点是额外占用更多PC。
图一显示了这个布局。作为文件系统，主要功能无非是，1. 存放文件，2. 读取文件。
存放：网络爬虫（Crawler）下载了形形色色的网页后，把这些网页发给存放目录的PC，简称目录服务器（master）。目录服务器决定用哪个PC来存放这些网页，简称数据存储器（ChunkServer）。
读取：等到有人想读取某个文件的时候，他可以向目录服务器发出请求，后者做以下几件事情，1. 先查询目录，确定文件存放在哪个机器，2.去目标机器读取所需文件，3. 把该文件返回给用户。
这个设计有以下几个主要问题。
1. 是否有必要占用额外PC，专门用来做目录服务器？譬如可以在数据存储器中，拨出一部份硬盘空间和内存，来存储目录。
这个办法是可行的，缺点是占用了一部份本来用来存放数据的硬盘以及内存空间。
另外一个缺点是，目录服务器通常很忙碌。如果存放文件甲的PC，同时兼做目录服务器，那么读取文件甲的速度，可能会低于读取其它文件的速度。
2. 无论存放还是读取文件，都必须经过目录服务器。数据存储器很多，但是目录服务器只有一个，千军万马过独木桥，目录服务器成为瓶颈。
解决办法是优化数据流的组织，我们在以后的章节中深入探讨。
3. 负载不均衡。譬如前一段时间，有关奥运会的文件被频繁读取，存放那些文件的数据存储器负荷很重。同样，存放某些经常被调用的程序的数据存储器，负荷也比其它机器重得多。
解决办法是优化负载均衡，甚至动态优化负载均衡，我们在以后的章节中深入探讨。
4. 万一某个数据存储器死机了，就会造成一部份数据无法读取。
解决办法是备份。把同一份文件，同时存放在多个PC上。当一台甚至多台PC死机了，只要还有一台PC正常工作，就可以正常读取文件。
图二显示了三个备份的布局。
这个布局有什么缺陷？且听下回分解。
本帖一共被 3 帖 引用 (帖内工具实现)
讲GFS的数据流和控制流的组织和优化，如何？
我觉得，先捡容易的讲，把困难留到后面，或许读起来会顺畅些。尊意如何？
送花！
顺便请教一下消息来源~~~ 
其实说白了，我不过是把Google的一些公开出版的论文，消化打碎了，用大白话重新讲一遍而已。
http://research.google.com/pubs/papers.html#DistributedSystemsandParallelComputing
之所以用一种比较通俗易懂的方式，重新叙述，动机是尝试着，能不能把貌似枯燥的学术问题，讲得有趣而已。
注意到西西河经济版的几位大牛，把经济金融这些本来很专业的内容，写成雅俗共赏的文章。我们能不能复制他们的经验，在computer science方面也做同样的努力呢？
备份＝冗余＝价格翻番＝维护翻番＝用电量翻番
至今为止的内容，都是非常基础想当然都可以想出来的，不知道后面有什么振奋人心拨云见日的东西。
期待期待
GFS，BIGTABLE,MAPREDUCE都思路很简单。但是都是工程做到极致的产品。现在做这几项的领军人物都是google的fellow了。
数据量一大，什么都可能出问题。比如说写数据写到一半，一台机器死机了，上面的数据怎么处理。Master机器死机了该如何处理。
还有就是对外提供的编程接口与任务调度。
思想和实现还是有相当一段距离的
当初怀着敬畏的心情读Google解剖那篇论文，读完以后，感觉没什么拍案叫绝的东西嘛。
再读，又重生敬畏。你看，关于压缩算法，老生常谈的题目，Googler比较了5-6种现成的算法，觉得都不满意，于是自己动手，做了一番改造。
Google的系统，的确没有开天辟地的东西，但是他们精细踏实。说起来容易，但是很少有人能坚持下去。
The Anatomy of a Large-Scale Hypertextual Web Search Engine?
对，就是这篇文章。
美国名校的高等XX课，譬如高等OS，高等人工智能，等等，多半是开学时，任课教授指定20来篇论文，让与课学生们读。然后每一节课，由某一位学生领读，其他学生相互讨论，而教授的职责是点拨一下。
貌似上这种课，教授的负担很轻，但是教授的水平往往体现在选用哪些论文让学生们读。
换一个角度，如果谁的论文被这些高等XX课，列为指定读物，对于论文的作者而言，是莫大荣幸。
对于Google的两位年轻的founders而言，他们的论文不仅被名校列为必读论文，而且同时被高等OS和高等人工智能课列为必读论文。尤其是这两位年轻人写这篇论文时，不过是博士班二年级学生，真是莫大莫大荣幸。
机器集群，去中心化，负载均衡，内存/硬盘的tradeoff，备份，对人的智慧的利用，相关性，这些东西就好像lego的各个部件，合理的组合起来就是一个系统了。
不过，说到论文，不仅让人想起那只在打字的兔子