主题：请教：关于大流量网站的架构问题 -- kingcu

有朋友在国内想建一个网站，考虑到以后流量可能会很大，打算做成像Google那样的架构：用普通的PC做服务器，流量增加的时候，相应增加服务器的数量即可。Google的一个cluster有几千台普通PC构成，在全世界有多个cluster，是用软件做的Domain Name Resolution，硬件做的Load Balancing。这个链接是我找到的介绍Google服务器架构的，但是没有详细的implementation detail。河里有没有知道的牛牛，请指点一二。凡答复者一律花谢。

他的那一套东西无法用普通PC来实现的。

另外，大量使用普通机器要注意电源和空调的问题。新的高密度机架安装的服务器对于耗电和散热有所照顾了，但是普通的PC可能就没有。

那个什么page rank根本就是marketing的噱头。 倒是这个分布式数据库，IBM，微软，Oracle做了十几年也没搞出个象样的产品，牛皮倒是吹了不少，结果人家google自己不单做出来了，而且实际证明非常成功。没有google那个架构，就没有google了。 所以如果你也想弄那么个架构，还不如直接说想复制个google更能让人动心。

CPU谁都能买到，但是超级计算机不是大家都有。

这个技术不是搭积木的方法就能搞定的。

Apache和MySql都是支持Cluster设置的，以后应该可以看看哪里是瓶颈就多挂服务器在那里即可。

Google的架构涉及的东西复杂很多，我想大部分情况下不需要做到它那种地步。

那么在实际使用中Apache和MySQL的cluster最多能加多少服务器呢？如果要用J2EE Application Server，比如JBoss的话，它的cluster又能支持多少Server呢？另外，如果用这种cluster结构的话，是不是对其中每一个服务器的要求都比较高，不能用太一般的机器？

如果说google的架构比较特殊，仅此一家的话，那么Amazon,eBay是怎么样架构的呢？

用大批普通PC，应该是Yahoo先这样的，当时也算一个应用经典。只不过现在啥都说Google了。

没必要考虑那么多吧，基本点是分层，WEB SERVER可以多台流量控制，可以随时增加减少，DATABASE SERVER分离出来只做数据存取。这就很够用了。数据库还可以类似的再分层，根据业务而定。

如果这还不够用，那说明你的网站极其成功，那时候再考虑更大的问题，苦恼也是快乐的呀。

最多支持63个节点，对每个节点没什么特别的要求。根据文档，4个双cpu节点可以每秒10万个查询。我想这对于一般网站肯定够了。我听说youtube也是用的mySql cluster。

Jboss不是很清除，可能文档也有吧。

光要个设计方案的话，5万块一个月也许也可以。

这个东东一般的大牛都是搞不定的，在这里问基本上是浪费时间。

老兄这个设想，比他们的难度更高，要想这里的兄弟给你拿主意

确实太难。 再牛的人，这事没个三四个月也搞不定。

照你的要求这件事已经成了个科研项目了。真要合作研究出来的花费

已经超过了买服务器的价格了。 那就还真不如用个普通

的架构设计呢。 用负载均衡路由器带几台正式的服务器，forget

这个普通 PC 的主意吧。

google之所以用自己的分布式文件系统GFS，以及建立在GFS之上的big table分布式数据库，都是因为它自己的应用特性决定的。反过来，GFS和big table也是针对google的应用特性来设计和优化的。

首先，google在后台对crawler扒来的网页数据进行处理，进行大规模的矩阵运算，来得出page rank，这本身就是要消耗大量的CPU cycles，所以server farm对它来说是最便宜的CPU资源了：400块一个白盒子，简直就是白菜。同时得到的还有更加廉价的硬盘空间。

而google big table分布式数据库，从google发表的论文里面可以看出一鳞一爪，那就是：big table是面向添加优化，而非面向修改优化，另外big table是面向文本内容而非面向二进制内容优化的。这些都是为了google搜索服务的。

你的朋友的网站，其实一开始不必考虑那么多，用不同的二级域名做一下负载均衡，设计的时候考虑一下，对可能的负载瓶颈，比如mysql服务器，做一下均衡，就可以了。等真的流量上去了，再重新设计不迟。

国外的不也还有WIKI这个网站可以参考么。呵呵

开源项目的LVS，HADHOOP现在都已经很成熟了