HAProxy提供高可用性、负载均衡 以及基于TCP和HTTP应用的代理，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。 HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上， 如下所示：
当前，您有两种主要的版本可以使用：
另外, 版本1.3是处于活跃开发阶段的版本, 它支持如下新特性：
和其他"免费"的负载均衡解决方案不同的是, HAproxy仅被几百或者几千的遍布全球的用户使用， 但是这些用户通常运行很大的站点， 每天有数百万的点击量和几Gbps甚至几万兆(terabytes)吞吐量。 他们需要7x24的可用性并且愿意承受免费软件解决方案的风险， 同时有这些使用技术. 通常, 这种解决方案仅配置为内部使用, 我仅在他们提供给我反馈或者需要新特性的时候才会知道.
设计选择和历史
2009年9月26日
September 24th, 2009 : 1.4-dev3
Compared to latest stable 1.3.20 version, 1.4-dev3 provides new features, among which support for the CLF log format, RDP protocol load-balancing and persistence, a new interactive CLI, an improved HTML stats page, support for inspecting HTTP contents in TCP frontends and switching to HTTP backends (allowing HTTP+SSL to coexist on the same port), support for forcing of the TCP MSS on frontends, smart network optimizations to reduce the number of TCP packets in a session, runtime-configurable buffer sizes, support for more than 64k concurrent connections, config parser support for "no option xxx" to disable options that were enabled by default, and correct 1xx status code processing. Developments to support keep-alive have already started, and if time permits, SSL integration will be attempted. The code looks amazingly stable for the amount of changes, and will probably not change much anymore, so any bug found in this version must be reported and fixed. Also, new feature submissions should be based on this version. It will be easier to implement for submitters and for me to merge.
Several large sites are already running on 1.4-dev2 with great success. This one should be even better, but given the number of changes, it should be monitored more closely at the beginning.
Last, I have a very good news that I hope will give ideas to others : Exceliance and Loadbalancer.org have both agreed to contribute some manpower and money to implement the complete persistence framework that everyone is dreaming about into haproxy. That's a tough work and I'm not certain it will be ready for 1.4 (though it might, depending if I'm as late on my releases as usual). I would personally like to thank them both for their contributions. When you have to put your money in commercial solutions, please never forget to consult first the guys who involve time and money in opensource projects, because they are the ones who help the projects evolve and live !
最近新闻...
| 分支 | 说明 | 最后版本 | Released | 注意 |
| 1.3.x | 开发 | GIT | 未发布 | 也许不稳定 |
| 1.3.16 | 1.3.16-rc | 1.3.16-rc1 | 2009/03/09 | Release Candidate (Beta) |
| 1.3.15 | 1.3.15-maint | 1.3.15.7 | 2008/12/04 | 推荐版本 |
| 1.3.14 | 1.3.14-maint | 1.3.14.11 | 2008/12/04 | 之前版本 |
| 1.2.x | 1.2-stable | 1.2.18 | 2008/05/25 | 仅修复重要bug |
| 1.1.x | 1.1-stable | 1.1.34 | 2006/01/29 | 仅修复致命bug |
| 1.0.x | 1.0-old | 1.0.2 | 2001/12/30 | 无维护 |
HAProxy提供高可用性、负载均衡 以及基于TCP和HTTP应用的代理，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。 HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上， 如下所示：
当前，您有两种主要的版本可以使用：
另外, 版本1.3是处于活跃开发阶段的版本, 它支持如下新特性：
和其他"免费"的负载均衡解决方案不同的是, HAproxy仅被几百或者几千的遍布全球的用户使用， 但是这些用户通常运行很大的站点， 每天有数百万的点击量和几Gbps甚至几万兆(terabytes)吞吐量。 他们需要7x24的可用性并且愿意承受免费软件解决方案的风险， 同时有这些使用技术. 通常, 这种解决方案仅配置为内部使用, 我仅在他们提供给我反馈或者需要新特性的时候才会知道.
HAProxy实现了一种事件驱动, 单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。
我从1996当我写Webroute时开始写一个简单的HTTP代理，此代理能建立一个modem访问。 但它的多进程模型的使得它从性能上只能用于home access。两年后，1998年，我写了事件驱动 的ZProx, 用于压缩TCP流量以加速modem线路。 那时我开始理解事件驱动模型的困难。2000年，在对一个小的应用程序做基准测试时，我大幅的修改了 Zprox以加入HTTP头重写支持。HAProxy的原型由此诞生。第一个版本自身并不实现负载均衡， 但很快被证明那是很需要的。
现在到了2007年, HAproxy的核心引擎已经很可靠而且很健壮，尽管代码里有许多的注释。事件驱动程序是健壮同时又 易崩溃的: 它的代码需要很小心的修改，但结果是它能处理高负载且能够不被攻击打倒。这也是为什么HAProxy仅有限的一些 特性的原因。
需求 SSL 和 Keep-Alive支持的用户。这些特性会使代码变得非常复杂而且会导致多个版本易于崩溃。而且， 这两功能都对会使性能下降:
不过，我计划在未来的版本中实现这两个功能，因为似乎有些用户的可用性需求高于性能需求，而且对他们来说， 使用这两特性并不会影响他们的性能而且可以减少其他组件数目。
支持的平台
HAProxy目前可以可靠的运行于以下（OS）平台:
运行于Linux 2.6或者打过epoll 补丁的 Linux 内核 2.4上，1.2.5以上版本的haproxy能达到最佳的性能。仅因为一项系统相关的优化：1.1版本默认的poll系统是 select(), 这在大多数操作系统上可用，但是在处理上千个文件描述符时会变得很慢。1.2 默认使用 poll() 替代之前的 select(), 但在某些系统上会比select更慢. 但是, 推荐在Solaris上使用，因为poll在它上面的实现是非常好的. Linux 2.6或打过补丁的Linux 2.4, HAProxy 1.2 默认使用epoll()， epoll在任何压力下都能达到 O(1) 性能, 所以比在其他系统上使用 poll() 或 select() 都更快. FreeBSD因为使用kqueue机制，性能比这个稍强. HAProxy 1.3开始支持这种poller, 但目前并没做基准测试。
基于这些事实，寻找快速负载均衡器的人们可以考虑运行于下列x86或者x86_64硬件的选择：
注意: 如果你在寻找一个飞速 的web负载均衡解决方案, 我测试过的第二快的平台是HP-DL145 (Dual Opteron-248 at 2.2 GHz)运行于打过 epoll patch的 Linux 内核 2.4 和 haproxy-1.2 上，达到了21000 hits/s 和2 Gbps.对这样一个廉价的系统来说，确实令人很震撼! 最快的是一台 Sun V40Z (Quad Opteron-848 at 2.2 GHz)，它在2G的链路上跑到了30000 hits/s . 这比Dual-proc高了50%多, 所以我猜测我们已经到了系统的极限了。另外一方面，系统方面的性能优化也可以大大的提升性能。总之，Dual-Opteron仍然为最佳性价比.