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

先看看架构图：

实际上是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当机时，它并不会自动切换到另一台，就这个问题看来这个模块暂时还是不好使。