睿普专栏负载均衡之：Haproxy概览分析
Posted 睿江云计算
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了睿普专栏负载均衡之：Haproxy概览分析相关的知识，希望对你有一定的参考价值。
小普
睿普小课堂又开课咯！今天我们来一起聊聊Haproxy
Haproxy描述
haproxy 是一个代理服务器，其工作就是将用户（下面简称客户端）的请求，尽量均衡的转发到应用服务器（下面简称服务端）。再将应用服务器的应答，发送给用户。
下面对haproxy的几个主要部件做一下概要分析
↓↓↓
主要“动力”结构
Haproxy本身有2个“动力源”，来推动这个过程的发生：
A） 网络事件池（类似libevent）主要包括以下事件：
监听客户端（用户）连接请求
监听从客户端读数据请求（stream_sock_read）
监听向客户端读数据请求
监听向服务端（应用服务器集群）写数据请求（stream_sock_write）
监听从服务端读数据请求
B） 任务循环。 主要有以下任务：
不停的检测是否可以连接到应用服务器集群中的服务器，如果哪台服务器持续连不上就不会将用户请求转发他。
每个用户请求会申请一个新的任务，每个任务对应一个相应执行函数process_session 。
process_session 还将根据这些状态执行一些操作。主要包括：
关闭与客户端和服务器的连接。释放资源。
关闭与客户端和服务器的连接。释放资源。
发起与应用服务器端的连接。
解析用户请求的头，和响应的头，根据配置文件规则，对请求头的某些域执行相应的操作（增加，覆盖，删除等）；
工作流程
读取配置，并根据它初始化全局资源。
与服务器群建立连接，并添加任务，监听这些服务器是否正常。
绑定端口将监听客户请求套接字加入，网络是库。监听用户请求
当监听到用户请求来时，新建任务process_session 用来维护客户端请求，以及状态。并将监听从客户端读数据stream_sock_read添加到网络事件池中。
stream_sock_read 从客户端读取数据。
process_session任务建立与服务器的连接，并将与服务端读写数据，添加到网络监听事件池中。
process_session解析用户端读来的数据。并做相应的加工后通过stream_sock_write发生给服务端
从服务端读取数据，通过返回给客户端。并关闭连接释放资源。
【注】： 4 -> 8 是在while中，最重要的是haproxy是个状态机模型。
内存管理
haproxy 内存管理. 采用了池的策略，进行统一管理。提供了回收链，可以提高分配性能。可以打印内存池正在使用的内存详细数据，这对内存泄漏好处多多。 缺点你需要自己管理每次分配的内存指针（因为haproxy, 更像提供一个工厂，释放内存必须主动），没用解决多次申请分配内存容易内存碎片的问题。因此与memcache以及操作系统malloc的内存管理相比还存在一点不足。
acl
haproxy 通过acl 完成2种主要的功能
（1）acl检查非法http请求，相应,如果不符合规则（规则是用户配置）直接中断请求。
（2）通过规则可以动态选择响应proxy.(类似于业务群）
特别说明： acl 规则很强大，支持规则与或非关系。
请求以及相应头解析
采用状态模型进行解析。具体参考一下rfc1945
使用静态数组链的方式，实现零拷贝。
网络事件驱动
只是对epoll, poll, select 等一套api封装。 然后支持通过宏选择相应的方式。
会话管理
haproxy, 一般对一个新的用户请求会尽量通过均衡策略，发到相应的服务器。但是如果来自同一个用户请求，因为涉及到会话管理，应该发到统一服务器。haproxy 主要有2种方式来保证。
是通过在cookie 里添加字段 proxy.cookie = server->cookie.。带上服务器标识
会话管理。 在cookie 里添加proxy.appsessionName = xxx . 而且每个proxy有个map<xxx, server.sid>
配置文件
和apache 配置文件一样，基本通过配置就可以控制haproxy其行为,支持为每个proxy（我把他理解成1个proxy,对应1个业务的服务器集群）单独配置，不过haproxy没用考虑到第三方模块开发。是个不小的遗憾。
本文部分内容转自互联网，已修改
点击“阅读原文”，了解更多干货资讯
以上是关于睿普专栏负载均衡之：Haproxy概览分析的主要内容，如果未能解决你的问题，请参考以下文章