主题：【原创】闲话Google集群 [1] 引子 -- 邓侃

Google的分布集群技术没用过，但是不敢苟同。其他存储技术倒是经常用CIFS, NFS, Nas, iSCSI, FCP...

这里边么FCP SAN是最快的了， NFS么就不怎么样，跑数据库那是经常被锁。

大家不知道发现没，大约3个月前，有家网上购物网站的图片显示非常的慢。为什么呢？ 就是他们开始用了google的集群技术了。

很好的话题，很有兴趣的点进来，不过看完后感觉随便了点。

有些关键内容讲的不够精确，诸如5个9,小数点后5个9，现在谁能做到？

电力供应能做到5个9，那也是小数点后3个，加前面2个的一起算的。

小数点后2个9的指标对于应用类的网站来说，已经是可望不可及的目标了，这意味着全年停机只能少于53分钟，昨天晚上我们做维护，一个在ebay工作过的工程师穿了件Ebay达到的最高可用率的T恤，数字很醒目，99.961%，这可是ebay的历史最高了。

对于存储的那段论述，名词堆砌是不解决问题的，关键是要指出重点。

BTW：据称，google的集群是自己生产的服务器，DELL的服务器的耗电和散热指标都不是太好的。

这个话题是个非常好的话题，希望能够在这个帖子中看到更准确，更专业的分享。

google的集群实质是一堆山寨机，硬件上基本没什么高技术（除了那个交换机是特殊的）。

你提到的CIFS, NFS, Nas, iSCSI, FCP，对google而言是阳春白雪了。

所以，如果一秒钟有1000次访问，google的性能是很差的。但如果一秒内有1000000000次访问，这些阳春白雪就要“咣铛”了，而google却还是能挺住。

所谓各擅胜场而已，关键在满足业务需求，这才是系统架构的王道！

不过，scalability尤其是数据（库）的scalability现在是整个IT界的最热点，当然iPhone除外，呵呵。

看得出来，这种标题一打，眼球马上就能吸引来，堪比眼下铺天盖地到处狂炒的cloud了。比起互联网规模的SNS面临的挑战，传统的企业内的那些IT话题，SOA了，n-tier了，数据结构了等马上都是小儿科了，企业内的科题现在基本沦为老印们外包混犯吃的家伙了，没太多油水可榨，因为从技术角度讲已经非常成熟了，也就只能在cost上动动脑筋了。一个常见的例子是，在fortune 500做架构师的到了那些大型SNS的startup那里，根本没有做架构师的资格，无他，需要解决的问题根本不在一个数量级上，因此从理论基础到工具方法全部需要换个角度，经验资历自然也就做不得数了。

自然，在没有成熟的理论实践指导下，这个领域内摸着石头过河的方式还是很流行，另外就是多方打听那些有一定成功的经验的系统的密诀，因此如highscalability.com这样的包打听blog就很引人注目。另外一个特点就是这个方向上的科研论文也是很热门，看来象牙塔里面也并不是两耳不闻天下事，对外面IT应用上的热点难题盯得很紧，至少互联发展起来这十几年有关的论文层出不穷，搜索了，界面了，数据了，网络了等方向上格外多。

因此，即然是个很前沿的话题，楼主这样随意的态度其实更好些，读者也少一些功利心，不要指望能发现什么武林密诀，作者自然就少些压力，重要的是头脑碰撞，当做一个共同学习的机会也很好。

1. 以Andy的身价，10万美元实在是九牛一毛。1998年10万美元的投资，到了2004年Google上市时，值多少钱？现在又增长到多少钱？不忍心计算，估计Andy后悔得肠子都青了

前面不是说已经签支票了吗？为何又说Andy后悔了？

坐等下文

一年停机5.3分钟，呵呵，虽然我知道传统电话网络很可靠，第一次听到这个数字还是震惊。

配好了就几个月才动一次，不像网络应用那么复杂。

google只用很少的dell服务器，所以从那里不可能估计出google的服务器数目。

每年全球生产的服务器在7M左右。如果google有10M服务器，那估计可占全球服务器的20%多，好像不大现实。

用CPU数目来估计比较合理，因为每个服务器有可能有2/4/8/16核。

是Social Network?

后悔投得太少了！

你说的是哪家网站？

SNS=Social Network Services = Seek & Sex

做系统架构，如果想做出一点名堂，一个投机取巧的途径是，要么做大，大到像Google集群那样的规模。要么做小，小到像iPhone那样，麻雀虽小，不仅五脏俱全，而且个个玲珑剔透。中间道路，虽然容易走，但是很难做出精彩。

前几天忙着搬家，耽搁了，这个星期加加油，着手写Google File System有关的架构。

所谓系统架构，听起来很玄，其实入门并不难。无非是机器布局，数据流控制流，同步，数据恢复（recovery），安全，等等。借着谈GFS，我们先把这几个要素过一遍。以后谈Bigtable，或者其它架构设计的时候，再炒一遍。

同样的实质，换着题目炒几遍，就熟悉了。熟悉了，就会出现有深度的辩论，乐趣就来了。

• 更专业的分享

回复见这里。：）

链接出处