1 月实践了一下haproxy  作为redis 的代理，统一了所有的redis 入口，对于应用来说，其实最好还是有一个全局的队列，这个中间层完全接管了mysql 和nosql 的写入读取。大工程啊，这里还是说一下简单的。

直接上配置吧：

我这里两个redis ，一个是active 状态对外服务，另一个是热备。

用redis-benchmark 来随便打了一下压力，和redis-cli 直连性能上差不多。

timeout 一定要配置，之前就是忘了配置，其中一个down 了以后很久都不切。

最近一次就是openfire 了，因为忘了当时做svn tcp 代理时的配置，弄得焦头烂额的。。。mark 下，以免以后再次需要的时候忘记了。

亚运赛事系统最初的系统架构，非常简单，就是前端用一堆组了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 。

log 127.0.0.1   local0

是不够的，即使你在 syslog 的配置里也写上了这句：

local0.*    /var/log/haproxy/local0.log

也还是不够的，haproxy 也不会把log 打印到相应的文件里。

需要修改 /etc/default/syslogd ，把

SYSLOGD=”"   修改为   SYSLOGD=”-r”

然后重启一下 syslogd

/etc/init.d/sysklogd restart

我的系统是 debian ，centos 没去测试，syslog 的配置上印象中有点不同的。

原因可以参考这两段东西：

man 8 syslogd :

-r     This  option will enable the facility to receive message from the network using an internet domain socket with the syslog service (see ser-
vices(5)).  The default is to not receive any messages from the network.

———————————–

less configuration.txt:

log <address> <facility> [max level [min level]]

<address> can be one of:

- An IPv4 address optionally followed by a colon and a UDP port. If
no port is specified, 514 is used by default (the standard syslog
port).

- A filesystem path to a UNIX domain socket, keeping in mind
considerations for chroot (be sure the path is accessible inside
the chroot) and uid/gid (be sure the path is appropriately
writeable).

———————————————

haproxy 可以把log 打印去两个地方，一个是 监听着 514 udp 端口的 syslog ，一个是 unix socket 。而 syslog 的 -r 参数，就是让 syslog 监听514 port 的。

又或者让 haproxy 连接去 syslog 的 unix socket 也行，

syslogd -a /etc/haproxy/syslog.sock  让 syslogd 监听在unix socket ，这时，haproxy 可以这样配置

log /etc/haproxy/syslog.sock   local0

此 socket 必须在 haproxy 的 chroot 环境中。

==========================
update:

centos 下，修改 /etc/sysconfig/syslog ，把

SYSLOGD_OPTIONS=”-m 0″

改为

SYSLOGD_OPTIONS=”-m 0 -r”

===========================

update 2011-03-25:

现在装的debian 下，一般使用rsyslog 了。

其实，以前的syslog 之所以要加 -r ，就是为了syslog 能监听514 端口，而在 rsyslog 中，-r 参数并不能令到它监听514 。

应该作以下修改：

/etc/rsyslog.conf 中

把注视去掉

# provides UDP syslog reception

$ModLoad imudp

$UDPServerRun 514