海量运维常用技术之----HAProxy网站负载均衡应用（获奖名单已公布-9-11）

Godbach

回复 40# HonestQiao
一条连接，如果 bufsize 是 8K，那么总共需要 17kB+ 的内存。
100K 的并发，用户空间内存就需要 1.7G+，内核空间需要的内存和这个数目差不多，double 一下。


   

Godbach

回复 39# HonestQiao

HAProxy 支持多种会话保持的配置，实际中哪种用的更多


   

fire_cpp

没用过haporxy，听闻其大名，也自己部署玩过，感觉是配置很方便，正则也很强大。但我们的应用没那么复杂，直接用nginx足够了，因为负载均衡器还担负另一个功能——静态文件服务，哈哈。静态文件不多，种构架跑得还是很顺的。

ylky_2000

yuhongchun 发表于 2013-07-11 16:22
HAProxy此时起的作用既是LB，又是反向代理，如果做了session处理的话，HAProxy这里会起分流作用，所以不 ...

看过您的书，对haproxy好像不怎么推荐。

csuduan

我现在所在项目组正好有用HAPROXY做负载均衡，所有对它的工作原理也做了一些了解，现在我来谈谈我对这两个问题的看法
1、acl工作原理：haproxy的acl 主要是针对7层的HTTP请求进行控制,ACL规则是在程序启动时解析配置文件的时候就建立好了（当然这里的正则表达式并非真正的正则表达式，只是作者参照正则表达式的样子定制的一些匹配模式罢了）。当有http请求达到haproxy的frontend（即haproxy监听的端口），haproxy会创建一个新task，将新task放入等待队列中。在这个task被唤醒后，执行会话处理（process_session），会有如process_switching_rules等对规则处理的函数被调用，这些函数会将当前请求的URI与所有ACL规则进行匹配，并根据匹配结果重定向到backend或者refuse掉请求。
2、acl在web服务器上可以根据URI做到对请求进行过滤、重定向等操作，非常实用。但是我在等项目请求基本都是tcp请求，所以不怎么用的上acl

3、haproxy+Heartbeat的方案没有了解过，但是对haproxy+keepalived知道点。所以不好点评两种方案熟劣熟优，那就谈谈我对这种部署方案的看法吧
     haproxy依靠作者的巧妙设计使得单进程可以达到百万级别的并发（我有看过源码，作者把这个程序参照操作系统设计，自己管理作业调度，它的一个task就相当于操作系统的一个进程，确实NB），在性能上无可挑剔的，但是作为企业级应用，这点是不够的，haproxy自身没有做任何高可用的保证，即haproxy所在机器都是单点，一旦宕机，业务将无法持续。keepalived洽洽是一款认可度非常高的高可用软件，keepalived通过虚拟IP，使多机（部署了haproxy的多台机器）共享VIP，但一个时刻只能有一台机器真正拥有这个VIP，一旦这台机器宕机，VIP将迁移到其他机器上，这些对外界来看是透明的，外界看来这个IP能一直提供服务。从而实现haproxy的高可用。
     这种部署方案也得到了Redhat的认可，redhat6.4已经将haproxy与keepalived加入到了安装光盘中，得到操作系统厂商的认可说明这种架构可行性非常高。
     这种部署方案我也部署过，并请求测试组同事用压力机测试过，效果很不错。但是这种部署方式最终还是被大boss否决掉了，最终采用的是F5+Haproxy的方式，F5先做负载均衡将请求转发至Haproxy集群中，Haproxy再做请求转发，利用F5的双机热备实现高可用。毕竟软件的实现的高可用跟硬件多机备份实现的高可用还是有差距的。




回复 1# send_linux


   

csuduan

action08 发表于 2013-07-10 13:18
亲爱的，可以看文档，cookie是个不错的方案，但haproxy可以有其他选择

硬件负载均衡主要产品就是F5，F5确实性能非常优秀，硬件级的嘛，直接利用背板进行转发（参照交换机路由器等）。F5也有很多型号，价格都很昂贵，动不动就40,50W。上百W的也有。但是相对Haproxy等软件负载均衡，在配置上缺落后很多。我接触到的这款F5有个相当坑爹的地方，它对端口配置，不不止一段端口，不支持通配符。前阵子让数据中心给配置一段端口20001到20600，直接被拒绝掉了，商量很久最后只肯给配30个，问了下原因是因为F5只能一个个配，而且每配置一个得生效一次，这个生效过程很长。即使这30个端口，还折腾了一下午。如果在软件中估计直接20001-20600这样描述下就OK了。