Skip to content


[转]WEB架构 – v.2008.163.com对新架构的尝试

先看看架构图:
163_nginx

实际上是app_nginx_squid_nginx的结构,nginx顶在最前面,具体有多少台我就不通告了,然后后面有比nginx更多的squid。

这个架构的特点是扩展了squid的功能,并且可以将很多请求绕过squid,实际应用时仍然出现一点问题,并在此系统的超级负荷下收获了不少经验。
为保商业秘密,只能告诉一个大概数字,此系统带图片的负荷每日在2亿-5亿之间,nginx代理全部机器加起来每秒处理的并发数日常总共是10000左右。
另说说每秒并发如何计算,跟据测试和对比,在web最前端每秒并发=系统的established/web server的keep alive。如果不是前端,那就不那么好算了,在这个系统中squid的established极低,不到10个,所以铁定不能从这个数字去判断了,可以使用squid的mgr:info来查看。
在这样的负荷下工作,平常运行时是没有很大的问题,就是在爆发地震性新闻那一小段时间难于招架。
于是我检查了系统,发现几个问题,并相应对系统进行了优化:
1、调整nginx的超时设置
我一般都会把nginx的超时时间设得稍微长一些,免得会抛出504错误,所以一般设为5分钟,但是在高负荷下,nginx总是能探测到很多的超时,经过测试,因为nginx前端堆积过多这些超时的请求,所以nginx的cpu占用率会上涨,最后nginx前端负荷过高,但后面一级的squid应该也负荷同样多的超时请求,但它却好得很。这样看来,nginx代理在处理这些超时请求上还有待提高。所以我调整了超时设置,将超时限定为5秒,这下负载就下来了不少。因为nginx超时后会重新选择一个后端请求,所以对访问影响不大,客户端同时也不会在一个超时请求下等待过长时间,这样就更为友好。
2、将图片用nginx缓存
鉴于nginx代理会出现问题,干脆把修改率不大的图片用nginx缓存起来,直接对外访问好了。于是使用proxy_store配置了一下,图片放到 /dev/shm内存里,然后写一个shell每小时把这些图片全删掉重取。放在内存里删除文件那是快啊,那么多图片一闪就删完了。
这样做下来,nginx的负载就很低了,处理同样的并发量,load average从2直降到了0.2,这时我觉得甚至只用单台nginx都可以工作。
ps:
在实际应用中也尝试了nginx的url hash模块,发现这个模块在有squid当机时,它并不会自动切换到另一台,就这个问题看来这个模块暂时还是不好使。

Posted in 网站架构, 技术.

Tagged with , .


4 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. unixhater.com says

    sudone.com转的吧?网易大牛啊,可惜他的网站不支持RSS

  2. C1G says

    techweb上转的哈,那图应该是sudone上的

  3. 代写 says

    路过,博客不错!

  4. cherry says

    收集不错的文章也很好呀,呵呵



Some HTML is OK

or, reply to this post via trackback.