Comments on: 说说大型高并发高负载网站的系统架构（更新） http://www.toplee.com/blog/71.html 活到老，学到老 ... Sat, 04 Jul 2009 16:21:12 +0000 http://wordpress.org/?v=2.7.1 hourly 1 By: xvm03 http://www.toplee.com/blog/71.html/comment-page-3#comment-31332 xvm03 Wed, 17 Jun 2009 02:57:54 +0000 http://www.toplee.com/blog/?p=71#comment-31332 必须留个脚印，搜索图片服务器方面的文章，无意中来到这里，不仅仅是技术牛，人品更是没话说，顶，以后要经常过来学习学习:) 必须留个脚印，搜索图片服务器方面的文章，无意中来到这里，不仅仅是技术牛，人品更是没话说，顶，以后要经常过来学习学习:)

]]> By: Joewere http://www.toplee.com/blog/71.html/comment-page-3#comment-31331 Joewere Tue, 16 Jun 2009 15:31:52 +0000 http://www.toplee.com/blog/?p=71#comment-31331 相当不错的一篇文章，经典得连回复我都看完了。恨自己太菜，只能摄取不能分享，不禁泪流满面....希望博主加油，写出更好的文章来。 相当不错的一篇文章，经典得连回复我都看完了。恨自己太菜，只能摄取不能分享，不禁泪流满面….希望博主加油，写出更好的文章来。

]]> By: tianjing http://www.toplee.com/blog/71.html/comment-page-3#comment-30882 tianjing Wed, 18 Feb 2009 04:20:21 +0000 http://www.toplee.com/blog/?p=71#comment-30882 我看到zhang 说到了myspace中提到“MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例” 这种方式虽然可行，但是MySpace是高度交互的，MySpace上的用户之间的关系呈网状的。如果这样的话，那么这100万组中的用户希望访问另一个100万组中的用户，并且发表评论，加为好友等等，是不是又存在不独立了？这种情况怎么解决呢？ 我看到zhang 说到了myspace中提到“MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例”

这种方式虽然可行，但是MySpace是高度交互的，MySpace上的用户之间的关系呈网状的。如果这样的话，那么这100万组中的用户希望访问另一个100万组中的用户，并且发表评论，加为好友等等，是不是又存在不独立了？这种情况怎么解决呢？

]]> By: abc http://www.toplee.com/blog/71.html/comment-page-3#comment-30830 abc Tue, 03 Feb 2009 03:45:48 +0000 http://www.toplee.com/blog/?p=71#comment-30830 不错，对我有启发。 本人也开发了一个网站www.guyazi.com,更多的是从软件技术啊方面考虑这些问题。 不错，对我有启发。

本人也开发了一个网站www.guyazi.com,更多的是从软件技术啊方面考虑这些问题。

]]> By: 学习linux http://www.toplee.com/blog/71.html/comment-page-3#comment-30577 学习linux Tue, 23 Dec 2008 13:09:20 +0000 http://www.toplee.com/blog/?p=71#comment-30577 可惜啊，今天才看到这个文章，楼主真是太好了！ 谢谢谢谢，学到很多东西！ 可惜啊，今天才看到这个文章，楼主真是太好了！ 谢谢谢谢，学到很多东西！

]]> By: Michael http://www.toplee.com/blog/71.html/comment-page-3#comment-28760 Michael Wed, 25 Jun 2008 03:59:43 +0000 http://www.toplee.com/blog/?p=71#comment-28760 从架构上来说，有多少资源用多少资源也是原则，不能为了追求架构而不考虑投入也是不可取的，你目前的情况来看，代码、服务器本身的配置优化看来应该有空间可改进，这个需要根据你具体的产品和代码来判断了。 有关数据库的缓存，又回到我文章里面谈的一些观点了，大概就是这些方法，万变不离其宗。 从架构上来说，有多少资源用多少资源也是原则，不能为了追求架构而不考虑投入也是不可取的，你目前的情况来看，代码、服务器本身的配置优化看来应该有空间可改进，这个需要根据你具体的产品和代码来判断了。

有关数据库的缓存，又回到我文章里面谈的一些观点了，大概就是这些方法，万变不离其宗。

]]> By: Pollux http://www.toplee.com/blog/71.html/comment-page-3#comment-28596 Pollux Mon, 23 Jun 2008 07:03:14 +0000 http://www.toplee.com/blog/?p=71#comment-28596 谢谢Michael，因为这个架构我也是接手在做，而关于这块的架构我目前只有建议的权限，决定权还是在高管层，squid也不是如您说的那样分布在各地，而是同web server一样，在同一机房，用于解决各地的访问的缓存是通过购买CDN服务实现的。关于动态的一些缓存，目前只是做到了数据库级，即对一些可能系统开销比较大，查询结果更改又不是太频繁的数据做了session database，不知道还有什么需要注意的地方。 谢谢Michael，因为这个架构我也是接手在做，而关于这块的架构我目前只有建议的权限，决定权还是在高管层，squid也不是如您说的那样分布在各地，而是同web server一样，在同一机房，用于解决各地的访问的缓存是通过购买CDN服务实现的。关于动态的一些缓存，目前只是做到了数据库级，即对一些可能系统开销比较大，查询结果更改又不是太频繁的数据做了session database，不知道还有什么需要注意的地方。

]]> By: Michael http://www.toplee.com/blog/71.html/comment-page-3#comment-28517 Michael Sun, 22 Jun 2008 05:26:19 +0000 http://www.toplee.com/blog/?p=71#comment-28517 [Comment ID #28474 Will Be Quoted Here] 这两天我的服务器硬盘有一块出错，昨晚刚恢复，没及时回复，抱歉。 如果你们的技术架构是你负责，你就应该要坚持你的观点，通常来说，web服务器一般都是部署在某个核心机房，各地的squid群起到负载均衡的作用，从这个角度来说，如果各地的点比较多，squid必然会比web服务器多很多，这是常规的做法，如果你要想让web服务器也分布太多点，这样架构会很复杂，没有太成熟的做法。 假如你的站点主要集中在一个点上，那你说的那种比例没有什么问题。 另外，你们的并发连接那个数量级，其实很小，因为你的内容主要还是静态的，虽然有动态的部分，实际上，动态的内容，有些情况下还是可以缓存的，需要更细致的去挖掘。

Pollux on June 20, 2008 at 10:11 pm said:

采购squid服务器的预算被枪毙了，主要是要实现squid服务器和web服务器1对1增加的服务器不在…

这两天我的服务器硬盘有一块出错，昨晚刚恢复，没及时回复，抱歉。

如果你们的技术架构是你负责，你就应该要坚持你的观点，通常来说，web服务器一般都是部署在某个核心机房，各地的squid群起到负载均衡的作用，从这个角度来说，如果各地的点比较多，squid必然会比web服务器多很多，这是常规的做法，如果你要想让web服务器也分布太多点，这样架构会很复杂，没有太成熟的做法。

假如你的站点主要集中在一个点上，那你说的那种比例没有什么问题。

另外，你们的并发连接那个数量级，其实很小，因为你的内容主要还是静态的，虽然有动态的部分，实际上，动态的内容，有些情况下还是可以缓存的，需要更细致的去挖掘。

]]> By: Pollux http://www.toplee.com/blog/71.html/comment-page-3#comment-28474 Pollux Fri, 20 Jun 2008 14:11:29 +0000 http://www.toplee.com/blog/?p=71#comment-28474 采购squid服务器的预算被枪毙了，主要是要实现squid服务器和web服务器1对1增加的服务器不在少数，而且网站现在动态的东西也不少，squid服务器并不能拦下来所有的访问请求，现有的web服务器平均iis并发连接都在30左右，个别二级域的站点服务器iis并发峰值都在100以上，所以web服务器已经不能再减少了，想请问一下Michael，挪一些web服器换成squid服务器以达到1：1的比例我，不知道会不会比现在这种web服务器多于squid服务器要好呢？ 采购squid服务器的预算被枪毙了，主要是要实现squid服务器和web服务器1对1增加的服务器不在少数，而且网站现在动态的东西也不少，squid服务器并不能拦下来所有的访问请求，现有的web服务器平均iis并发连接都在30左右，个别二级域的站点服务器iis并发峰值都在100以上，所以web服务器已经不能再减少了，想请问一下Michael，挪一些web服器换成squid服务器以达到1：1的比例我，不知道会不会比现在这种web服务器多于squid服务器要好呢？

]]> By: Michael http://www.toplee.com/blog/71.html/comment-page-3#comment-28386 Michael Wed, 18 Jun 2008 08:24:02 +0000 http://www.toplee.com/blog/?p=71#comment-28386 [Comment ID #28383 Will Be Quoted Here] 多台squid指向同一个web服务器，这是通常的做法，访问量大是增加squid，而不是增加web服务器，你尝试这样调整一下。

Pollux on June 18, 2008 at 1:51 pm said:

感谢Michael深夜回复，还是要多多注意身体啊。关于我的第2个问题，目前是这样子的，因为netsc…

多台squid指向同一个web服务器，这是通常的做法，访问量大是增加squid，而不是增加web服务器，你尝试这样调整一下。

]]> By: Pollux http://www.toplee.com/blog/71.html/comment-page-3#comment-28383 Pollux Wed, 18 Jun 2008 05:51:11 +0000 http://www.toplee.com/blog/?p=71#comment-28383 感谢Michael深夜回复，还是要多多注意身体啊。关于我的第2个问题，目前是这样子的，因为netscale设备的缓存机制是使用内存，非常小，所以主要是用它作负载均衡这块的，而Squid才是用来做缓存代理服务的，缓存代理的对象就是后端的Web服务器的内容，但由于访问量相当大，现在的相状就是后端的Web服务器比Squid服务器数量多出很多，而Squid因为是改hosts来实现指向某一台后端服务器，没有办法一对多，所以Squid只好再指回负载均衡设备netscale，由它再一对多到后端的Web Server上面。 感谢Michael深夜回复，还是要多多注意身体啊。关于我的第2个问题，目前是这样子的，因为netscale设备的缓存机制是使用内存，非常小，所以主要是用它作负载均衡这块的，而Squid才是用来做缓存代理服务的，缓存代理的对象就是后端的Web服务器的内容，但由于访问量相当大，现在的相状就是后端的Web服务器比Squid服务器数量多出很多，而Squid因为是改hosts来实现指向某一台后端服务器，没有办法一对多，所以Squid只好再指回负载均衡设备netscale，由它再一对多到后端的Web Server上面。

]]> By: Michael http://www.toplee.com/blog/71.html/comment-page-3#comment-28380 Michael Wed, 18 Jun 2008 04:22:54 +0000 http://www.toplee.com/blog/?p=71#comment-28380 [Comment ID #28378 Will Be Quoted Here] 嘿嘿，你手好了吗？ 好久没来打球了，周末过来一起玩儿吧。 好像你又开始折腾新东西了，小豆瓣 是新搞的吗？

xiaodouban on June 18, 2008 at 11:24 am said:

M总，领教了

嘿嘿，你手好了吗？ 好久没来打球了，周末过来一起玩儿吧。

好像你又开始折腾新东西了，小豆瓣 是新搞的吗？

]]> By: xiaodouban http://www.toplee.com/blog/71.html/comment-page-3#comment-28378 xiaodouban Wed, 18 Jun 2008 03:24:21 +0000 http://www.toplee.com/blog/?p=71#comment-28378 M总，领教了 M总，领教了

]]> By: Michael http://www.toplee.com/blog/71.html/comment-page-3#comment-28367 Michael Tue, 17 Jun 2008 17:20:56 +0000 http://www.toplee.com/blog/?p=71#comment-28367 [Comment ID #28351 Will Be Quoted Here] 1. 大量并发导致写文件失败是很常见的情况，基本上也很难避免，减小并发写操作是追求的目标，这要从产品层面来考虑。 2. 从你的信息来看，你目前的架构是因为按照id分组的文件太多导致，不过我没有理解，既然是squid，为什么后端需要那么多的web服务器？ 理论上 Load balance->squids->web servers 就ok了，这方面我估计需要了解你的细节。 3. netscale我没有用过，也是第一次听说，不过从你现在的情况来看，我建议使用别的7层交换设备或者软件来替换，这样可以根据你描述的文件的id来进行划分到不同的squid群，当然，如果继续使用netscale，由于大部分是静态页面，还是建议最小连接数的策略更高效。

Pollux on June 17, 2008 at 5:02 pm said:

Blog主您好，看了您的文章有一些问题想要请教一下，首先是目前我这边的情况，前端负载均衡使用nets…

1. 大量并发导致写文件失败是很常见的情况，基本上也很难避免，减小并发写操作是追求的目标，这要从产品层面来考虑。
2. 从你的信息来看，你目前的架构是因为按照id分组的文件太多导致，不过我没有理解，既然是squid，为什么后端需要那么多的web服务器？ 理论上 Load balance->squids->web servers 就ok了，这方面我估计需要了解你的细节。
3. netscale我没有用过，也是第一次听说，不过从你现在的情况来看，我建议使用别的7层交换设备或者软件来替换，这样可以根据你描述的文件的id来进行划分到不同的squid群，当然，如果继续使用netscale，由于大部分是静态页面，还是建议最小连接数的策略更高效。

]]> By: Pollux http://www.toplee.com/blog/71.html/comment-page-3#comment-28351 Pollux Tue, 17 Jun 2008 09:02:54 +0000 http://www.toplee.com/blog/?p=71#comment-28351 Blog主您好，看了您的文章有一些问题想要请教一下，首先是目前我这边的情况，前端负载均衡使用netscale，然后分布到多个Squids，最后面是IIS的WebSite，数据是html静态页面+xml存储在SAN上，存储时按ID号和类型区别分布在3套Cluster的20个映射驱动器上，目前遇到的问题如下 1、前台UI在保存xml(非html，静态页面完全由后台程序生成，前台页面只是写数据库和xml然后发送MSMQ，最后由后台程序生成静态页面)时偶尔会报写缓存失败导致保存用户信息的xml无法生成，目前看来应该是大量并发的原因，不知道有什么建议？ 2、由于目前我没有找到任何资料显示Squids可以一对多台后端服务器，所以现在使用的的是netscale-->Squids(多台)-->netscale（2个VIP分组）-->每个分组中包含的IIS服务器，这样一来所有的网络流量在负载设备基本上就翻了一翻，所以想请教一下有没有什么好的办法可以解决这个。 3、netscale的负载均衡策略可以选择最小连接数优先和最小响应时间优先以及平均分配，不知道使用哪一个会比较合理一些。 先谢谢了，我的msn是pollux_sky#hotmail.com(#换成@)，希望能有更多的机会交流。 Blog主您好，看了您的文章有一些问题想要请教一下，首先是目前我这边的情况，前端负载均衡使用netscale，然后分布到多个Squids，最后面是IIS的WebSite，数据是html静态页面+xml存储在SAN上，存储时按ID号和类型区别分布在3套Cluster的20个映射驱动器上，目前遇到的问题如下
1、前台UI在保存xml(非html，静态页面完全由后台程序生成，前台页面只是写数据库和xml然后发送MSMQ，最后由后台程序生成静态页面)时偶尔会报写缓存失败导致保存用户信息的xml无法生成，目前看来应该是大量并发的原因，不知道有什么建议？
2、由于目前我没有找到任何资料显示Squids可以一对多台后端服务器，所以现在使用的的是netscale–>Squids(多台)–>netscale（2个VIP分组）–>每个分组中包含的IIS服务器，这样一来所有的网络流量在负载设备基本上就翻了一翻，所以想请教一下有没有什么好的办法可以解决这个。
3、netscale的负载均衡策略可以选择最小连接数优先和最小响应时间优先以及平均分配，不知道使用哪一个会比较合理一些。

先谢谢了，我的msn是pollux_sky#hotmail.com(#换成@)，希望能有更多的机会交流。

]]> By: Michael http://www.toplee.com/blog/71.html/comment-page-3#comment-28271 Michael Sun, 15 Jun 2008 13:57:56 +0000 http://www.toplee.com/blog/?p=71#comment-28271 [Comment ID #28269 Will Be Quoted Here] 可以从alexa上得到一个网站一天的pv数量，然后再一除就大概知道并发多少了。 视频网站和传统的网站pv还有较大差别，比如新浪的一个pv就是看一个页面或者新闻，但是视频网站一个pv可能是几十分钟的一个片子。

zifa on June 15, 2008 at 7:41 pm said:

想问下多大并发才算是高负载 像6.cn这样的站最大并发多少

可以从alexa上得到一个网站一天的pv数量，然后再一除就大概知道并发多少了。
视频网站和传统的网站pv还有较大差别，比如新浪的一个pv就是看一个页面或者新闻，但是视频网站一个pv可能是几十分钟的一个片子。

]]> By: zifa http://www.toplee.com/blog/71.html/comment-page-3#comment-28269 zifa Sun, 15 Jun 2008 11:41:24 +0000 http://www.toplee.com/blog/?p=71#comment-28269 想问下多大并发才算是高负载 像6.cn这样的站最大并发多少 想问下多大并发才算是高负载 像6.cn这样的站最大并发多少

]]> By: Robert wrote related post http://www.toplee.com/blog/71.html/comment-page-3#comment-28061 Robert wrote related post Tue, 10 Jun 2008 11:11:18 +0000 http://www.toplee.com/blog/?p=71#comment-28061 <strong>Robert wrote related post...</strong> Silk posts and stories... Robert wrote related post…

Silk posts and stories…

]]> By: norasun http://www.toplee.com/blog/71.html/comment-page-3#comment-27925 norasun Fri, 06 Jun 2008 09:38:50 +0000 http://www.toplee.com/blog/?p=71#comment-27925 Michael，谢谢你，从文章到评论我一气看完了，除了感谢你的文章，也被大家这种浓烈的分享精神感动了，也学人家，在这里留个脚印。 Michael，谢谢你，从文章到评论我一气看完了，除了感谢你的文章，也被大家这种浓烈的分享精神感动了，也学人家，在这里留个脚印。

]]> By: Michael`s blog » MySQL数据库运用技巧和优化（不断更新） http://www.toplee.com/blog/71.html/comment-page-3#comment-27915 Michael`s blog » MySQL数据库运用技巧和优化（不断更新） Fri, 06 Jun 2008 02:28:44 +0000 http://www.toplee.com/blog/?p=71#comment-27915 [...] 说说大型高并发高负载网站的系统架构（更新） - 24,997 views [...] [...] 说说大型高并发高负载网站的系统架构（更新） - 24,997 views [...]

]]>