负载均衡之：Haproxy概览分析

Haproxy描述

haproxy 是一个代理服务器，其工作就是将用户（下面简称客户端）的请求，尽量均衡的转发到应用服务器（下面简称服务端）。再将应用服务器的应答，发送给用户。

主要“动力”结构

Haproxy本身有2个“动力源”，来推动这个过程的发生：

A）网络事件池（类似libevent）主要包括以下事件：

l监听客户端（用户）连接请求

l监听从客户端读数据请求（stream_sock_read）

l监听向客户端读数据请求

l监听向服务端（应用服务器集群）写数据请求（stream_sock_write）

l监听从服务端读数据请求

B）任务循环。 主要有以下任务：

l不停的检测是否可以连接到应用服务器集群中的服务器，如果哪台服务器持续连不上就不会将用户请求转发他。

l每个用户请求会申请一个新的任务，每个任务对应一个相应执行函数process_session 。

lprocess_session 还将根据这些状态执行一些操作。主要包括：

1.关闭与客户端和服务器的连接。释放资源。

2.关闭与客户端和服务器的连接。释放资源。

3.发起与应用服务器端的连接。

4.解析用户请求的头，和响应的头，根据配置文件规则，对请求头的某些域执行相应的操作（增加，覆盖，删除等）；

工作流程

1.读取配置，并根据它初始化全局资源。

2.与服务器群建立连接，并添加任务，监听这些服务器是否正常。

3.绑定端口将监听客户请求套接字加入，网络是库。监听用户请求

4.当监听到用户请求来时，新建任务process_session 用来维护客户端请求，以及状态。并将监听从客户端读数据stream_sock_read添加到网络事件池中。

5.stream_sock_read 从客户端读取数据。

6.process_session任务建立与服务器的连接，并将与服务端读写数据，添加到网络监听事件池中。

7.process_session解析用户端读来的数据。并做相应的加工后通过stream_sock_write发生给服务端

8.从服务端读取数据，通过返回给客户端。并关闭连接释放资源。

【注】： 4 -> 8 是在while中，最重要的是haproxy是个状态机模型。

内存管理

haproxy 内存管理. 采用了池的策略，进行统一管理。提供了回收链，可以提高分配性能。可以打印内存池正在使用的内存详细数据，这对内存泄漏好处多多。缺点你需要自己管理每次分配的内存指针（因为haproxy, 更像提供一个工厂，释放内存必须主动），没用解决多次申请分配内存容易内存碎片的问题。因此与memcache以及操作系统malloc的内存管理相比还存在一点不足。

acl

haproxy 通过acl 完成2种主要的功能，

1、acl检查非法http请求，相应,如果不符合规则（规则是用户配置）直接中断请求。

2、通过规则可以动态选择响应proxy.(类似于业务群）

特别说明： acl 规则很强大，支持规则与或非关系。

请求以及相应头解析

l采用状态模型进行解析。具体参考一下rfc1945

l亮点是为了实现0cp竟然使用了静态数组链的方式。

l网络事件驱动

l只是对epoll, poll, select 等一套api封装。 然后支持通过宏选择相应的方式。

会话管理

haproxy, 一般对一个新的用户请求会尽量通过均衡策略，发到相应的服务器。但是如果来自同一个用户请求，因为涉及到会话管理，应该发到统一服务器。haproxy 主要有2种方式来保证。

1)是通过在cookie 里添加字段 proxy.cookie = server->cookie.。带上服务器标识

2)会话管理。 在cookie 里添加proxy.appsessionName = xxx . 而且每个proxy有个map

配置文件

相当强大，和apache 配置文件一样，基本通过配置就可以控制haproxy其行为,支持为每个proxy（我把他理解成1个proxy,对应1个业务的服务器集群）单独配置，不过haproxy没用考虑到第三方模块开发。是个不小的遗憾。