Haproxy负载均衡
HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。
HAProxy实现了一种事件驱动, 单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。
包括 GitHub、Bitbucket[3]、Stack Overflow[4]、Reddit、Tumblr、Twitter[5][6]和 Tuenti[7]在内的知名网站，及亚马逊网络服务系统都使用了HAProxy。
配置HAProxy Session亲缘性的三种方式
haproxy负载均衡保持客户端和服务器Session亲缘性的三种方式:
1 用户IP 识别
haproxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令）
配置指令 balance source
2 cookie 识别
haproxy 将WEB服务端发送给客户端的cookie中插入(或添加前缀)haproxy定义的后端的服务器COOKIE ID。
配置指令例举 cookie SESSION_COOKIE insert indirect nocache
用firebug可以观察到用户的请求头的cookie里 有类似" Cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5; SESSION_COOKIE=app1" SESSION_COOKIE=app1就是haproxy添加的内容
3 session 识别
haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。
配置指令例举 appsession JSESSIONID len 64 timeout 5h request-learn
配置举例：
#vi /usr/local/haproxy/haproxy.cfg
backend COOKIE_srv
mode http
cookie SESSION_COOKIE insert indirect nocache
server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1
server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1
backend SOURCE_srv
mode http
balance source
server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1
server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1
backend APPSESSION_srv
mode http
appsession JSESSIONID len 64 timeout 5h request-learn
server REALsrv_70 184.82.239.70:80 cookie 11 check inter 1500 rise 3 fall 3 weight 1
server REALsrv_120 220.162.237.120:80 cookie 12 check inter 1500 rise 3 fall 3 weight 1
#启动haproxy
/usr/local/haproxy/haproxy -f
#查看是否启动
[zhangy@BlackGhost haproxy]$ ps -ef|grep haproxy
4859 ? 00:00:00 haproxy
4860 ? 00:00:00 haproxy
HAProxy监听的端口是1080，代理192.168.18.2:10000，127.0.0.1:10000
统计监听的是8888端口 http://localhost:8888/haproxy-stats
路漫漫其修远兮
