haproxy是一个非常优秀的负载均衡工具，它的特性非常丰富，功能也非常非常强大，要想好好使用它，将它的功能和性能挖掘出来，多多阅读官方手册是必不可少的。
本文提供一个简单的配置示例，后面将分别开文章详细解释它的配置文件、cookie会话保持、stick table的功能、haproxy主主模型的复制(replication)、抵御攻击等等。
1. 配置haproxy需要考虑的事情尽管haproxy大多数配置选项都可以采用默认配置，但有些选项，特别是关于实际需求、连接数和超时时间相关的选项必须独立配置。
大致总结了下以下几点需要考虑的问题：
haproxy支持5种http事务模型。一般只会选择其中两种：
(1).当后端为静态web或静态缓存服务器时，使用http-keep-alive模型，由于响应速度快，频繁建立tcp连接的代价比较大；
(2).当后端为动态应用程序服务器或者静态但传输的资源对象体积较大时，使用http-server-close模型，因为响应速度相对较慢，占用空闲连接的资源比建立tcp连接的代价更大。
haproxy反向代理的调度算法优先级是低于cookie的，因此当一个连接已经保持了会话，调度算法对该连接就无效。只有新的连接请求或者长连接已经失效时，才会使用调度算法进行调度。在调度算法的选择上，如果不考虑服务器性能差距的话：
(1).如果后端会话时间比较长(mysql)，建议使用leastconn，因为调度过程中，后端释放连接时动荡不大，比较稳定。
(2).如果后端是静态web，建议使用roundrobin算法。
(3).如果后端需要保持会话信息，但又不使用cookie时，可以使用源地址hash算法source，保证将同一客户端引导到同一后端服务器上。如果使用cookie，则可以使用roundrobin或leastconn算法。源地址hash算法，一般只在没有办法的时候但又要调度到同一后端服务器时，才作为最后手段。
(4).如果配置了session共享，则对于haproxy来说，动态资源的请求是"无状态"的，可以使用roundrobin算法或leastconn。
(5).如果后端是缓存服务器，为了保证命中率，建议使用uri算法，同时将hash-type设置为consistent方法(一致性hash)，保证后端缓存服务器down掉后对客户端的影响足够小。
haproxy是单进程、事件驱动模型的软件，单进程下工作效率已经非常好，不建议开启的多进程/多实例。
maxconn指令控制最大并发连接数，可以在多处设置，设置位置不同，代表意义不同：
(1).设置在global段或frontend/listen/defaults段的maxconn代表的是和客户端(即frontend)的最大连接并发数；其中global段的值是硬限制，frontend/listen/defaults段的maxconn值不能超过global段的值。
(2).设置在server指令中时，代表的是haproxy和某台后端服务器维持的最大并发连接数。
(3).前端的最大并发数(即global段的maxconn)可以根据内存来估算，haproxy为每个连接维持两个缓存区，每个大致16K左右，加上一些额外数据，共约33-34K左右，因此理论上1G的空闲内存能维持2W-2.5W个纯HTTP的并发连接(只是理论上)，如果代理的是https，则允许的最大并发数量要小的多。前端maxconn默认值为2000，非常有必要将其增加几倍。一般代理纯http服务时，如果后端能处理及时，这里设置20000以上都不会有什么问题。以上只是大致估算代理能力，实际设置时必须根据后端处理能力以及haproxy自身能力设置前端maxconn，否则将前端接进来后端也无法立即处理。
(4).后端所有服务器的maxconn值之和应接近前端的maxconn值，计算两者差距时，还需要考虑后端的等待队列长度maxqueue。其中和静态web服务器的maxconn可以设置大一些。
开启haproxy和后端的连接重用功能。当某客户端的请求到来后，haproxy和后端某服务器建立一个TCP连接，并将请求调度到该服务器上，该客户端后续的请求也会通过该TCP连接转发给后端(假设没有采用关闭后端连接的http事务模型)。但在响应后和该客户端的下一个请求到来前，这个连接是空闲的。和后端建立的TCP连接只是为了调度转发，保证持有合适cookie的客户端请求能调度到同一后端，完全可以为其它客户端的请求调度也使用这个TCP连接，保证TCP连接资源不浪费。可以使用http-reuse strategy_name指令设置连接重用的策略，而默认策略禁用连接重用。
(1).never：这是默认设置。表示禁用连接重用，因为老版本的haproxy认为来源不同的请求不应该共享同一个后端连接。
(2).safe：这是建议使用的策略。"安全"策略下，haproxy为客户端的每个第一个请求都单独建立一个和后端的TCP连接，但是后续的请求则会重用和该后端的空闲TCP连接。这样的转发不仅提高了资源使用率，还保持了keep-alive的功能。因此，safe策略配合http-keep-alive事务模式比http-server-close事务模式更高效，无论后端是静态、缓存还是动态应用服务器。