广州亚运亚残在今天落幕了，一班亚运的同事将要离职，真让人伤感。随便写篇东西纪念一下我为亚运付出的一个月。

亚运赛事系统最初的系统架构，非常简单，就是前端用一堆组了lvs 的 squid 作为cache server ，后端跑nginx+resin 。

这个架构，优点就是够简单，如果cache server 不够，就横向扩展，同样简单。

但是，当整个系统的瓶颈不在缓存端时，缺点也很明显了。我发现，后端的load 很容易跑高，特点就是，缓存时间比较短（1 分钟），然后前端的穿透较多，再且，前端的访问很散列，并没有特别的热点。这样，如果作横向扩展，只会对后端的压力越大，因为穿透更多了。

之前去听SACC 2010 的，其实很多公司都用了一层haproxy 做 url hash 。于是，就对现有的架构作一次调整，希望对当时的负载情况有所帮助。

调整后的架构是这样的：最前端是一堆组了lvs 的haproxy ，作用是url hash 到后端的cache 。nginx 其实也是可以做url hash 的，在这里，选择nginx 还是 haproxy 呢，功能上nginx 确实稍胜一筹，但性能上 haproxy 也略优，选择什么也可以按个人爱好来定。呵呵。cache server 端，我也做了小调整，因为不需要只使用一个80 端口了，我一台服务器上跑两个squid 。用taskset 把2 个squid 绑定到cpu1 和 cpu2（默认都是cpu0 ） ，让cpu0 处理系统调用，cpu3 处理网络io 。一台4G 的服务器，在这个情况下已经算是把服务器使用得很尽了。cachedir 一律使用内存分区，不要出现磁盘io 。

但这个架构也不是绝对无敌，url hash 最怕遇到热点，特别热那种，就像110米跨栏决赛和男篮决赛。因为单一的url 并发过高，而导致其中一个cache server 跑满了一个cpu（url hash 把这个url 都调度到这个cache ） ，众所周知，squid 只能使用一个cpu ，这个cpu 跑满载了，请求就会开始阻塞了。然后连接数不断彪高，直接导致了前端的haproxy 也挂了，同时骨牌效应，所有的haproxy 都挂了。。。无奈，只好针对这个url 做特殊处理，rr 分配到后端多个squid ，而不走url hash 了。真是害人不浅阿。。。如果可以预先知道将会是热点的url ，这个问题将会更好解决，而不是要到haproxy 挂了才去处理。

末了，贴一下haproxy 的url hash 配置吧：

global
log 127.0.0.1 local3 notice
ulimit-n 409600
maxconn 102400
chroot /home/haproxy
pidfile /home/haproxy/var/haproxy.pid
user haproxy
group haproxy
nbproc 4
daemon
quiet

defaults
log global
mode http
option httplog
option dontlognull
option redispatch
option forwardfor
option httpclose
option log-separate-errors
monitor-uri /do_not_delete/monitor.txt
retries 3
stats uri /haproxy-status
maxconn 102400
contimeout 5000
clitimeout 50000
srvtimeout 50000
stats auth admin:123456

frontend http_server
bind :80
default_backend info_cache
acl url_static path_end BKM400101.json
use_backend info_cache_temp if url_static

backend info_cache
option httpchk HEAD /live.js HTTP/1.1\r\nHost:\ info.2010.163.com
balance uri len 15 # url hash
server inst1 192.168.51.1:3128 check inter 5000 fall 3
server inst2 192.168.51.1:3129 check inter 5000 fall 3
server inst3 192.168.51.2:3128 check inter 5000 fall 3
server inst4 192.168.51.2:3129 check inter 5000 fall 3
server inst5 192.168.51.3:3128 check inter 5000 fall 3
server inst6 192.168.51.3:3129 check inter 5000 fall 3

backend info_cache_temp
option httpchk HEAD /live.js HTTP/1.1\r\nHost:\ info.2010.163.com
balance roundrobin # rr
server inst1 192.168.51.1:3128 check inter 5000 fall 3
server inst2 192.168.51.1:3129 check inter 5000 fall 3
server inst3 192.168.51.2:3128 check inter 5000 fall 3
server inst4 192.168.51.2:3129 check inter 5000 fall 3
server inst5 192.168.51.3:3128 check inter 5000 fall 3
server inst6 192.168.51.3:3129 check inter 5000 fall 3

其实这个架构只是一个调优，如果整套系统需要优化的话，还是需要从最初的设计入手，很多细节都要顾及。

细节包括，那些数据传输的地址，不要使用163.com 的，因为带了很大串的cookie ，用户每一次访问都带有这么一大串，是很占带宽的。还有根据不同的文件设置不同的缓存，这个最初没有设计好的话，js , css 等文件就混入到163.com 的域名中难以隔离。还需要根据具体的业务去配置一下缓存。业务数据，一定要从一开始就要有系统地收集统计，调优后对比分析。等等等等。。。

在这个架构下，前面的haproxy 只是纯代理，后面的cache server ，可以任意选择，经典一点的，可以用 squid 。或者上varnish ，再或者试用 ATS 。