博文参考
http://ju.outofmemory.cn/entry/218244http://www.cnblogs.com/gtms/p/6790939.htmlhttp://www.92to.com/bangong/2016/08-24/9737822.htmlhttp://blog.sina.com.cn/s/blog_704836f40102vrt0.htmlhttp://blog.csdn.net/jinshiyill/article/details/50824352
架构图
HAProxy概述
HAProxy简介
HAProxy主要提供两个功能：http协议反向代理(不提供缓存功能)、基于tcp层的负载均衡(如https、MySQL协议)。适用于需要会话保持或七层处理的且负载特别大的站点。可支持数以万计的并发连接。 代理作用：web缓存（加速）、反向代理、内容路由（根据流量及内容类型等将请求转发至特定服务器）、转码器； HAProxy基于一种事件驱动(event-driven)、单一进程模型和ebtree弹性二叉树机制。 多进程或多线程模型受内存限制、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务，所以并发响应能特别大。但在多核系统上此模型通常扩展性较差
性能优势
HAProxy借助于OS上几种常见的技术来实现性能的最大化。 单进程、事件驱动模型显著降低了上下文切换的开销及内存占用。 O(1)事件检查器(eventchecker)允许其在高并发连接中对任何连接的任何事件实现即时探测。 在任何可用的情况下，单缓冲(singlebuffering)机制能以不复制任何数据的方式完成读写操作，这会节约大量的CPU时钟周期及内存带宽； 借助于Linux 2.6 (>=2.6.27.19)上的splice()系统调用，HAProxy可以实现零复制转发(Zero-copy forwarding)，在Linux3.5及以上的OS中还可以实现零复制启动(zero-starting)； 内存分配器在固定大小的内存池中可实现即时内存分配，这能够显著减少创建一个会话的时长； 树型存储：侧重于使用作者多年前开发的弹性二叉树，实现了以O(log(N))的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列； 优化的HTTP首部分析：优化的首部分析功能避免了在HTTP首部分析过程中重读任何内存区域； 精心地降低了昂贵的系统调用，大部分工作都在用户空间完成，如时间读取、缓冲聚合及文件描述符的启用和禁用等；
HAProxy目前主要版本
1.4版本——提供较好的弹性：衍生于1.2版本，并提供了额外的新特性，其中大多数是期待已久的。
客户端侧的长连接(client-side keep-alive) TCP加速(TCP speedups) 响应池(response buffering) RDP协议 基于源的粘性(source-based stickiness) 更好的统计数据接口(a much better stats interfaces) 更详细的健康状态检测机制(more verbose health checks) 基于流量的健康评估机制(traffic-based health) 支持HTTP认证 服务器管理命令行接口(server management from the CLI) 基于ACL的持久性(ACL-based persistence) 日志分析器1.3版本——内容交换和超强负载：衍生于1.2版本，并提供了额外的新特性。
内容交换(content switching)：基于任何请求标准挑选服务器池；
ACL：编写内容交换规则； 负载均衡算法(load-balancing algorithms)：更多的算法支持； 内容探测(content inspection)：阻止非授权协议； 透明代理(transparentproxy)：在linux系统上允许使用客户端IP直接连入服务器； 内核TCP拼接(kernel TCPsplicing)：无copy方式在客户端和服务端之间转发数据以实现数G级别的数据速率； 分层设计(layereddesign)：分别实现套接字、TCP、HTTP处理以提供更好的健壮性、更快的处理机制及便捷的演进能力； 快速、公平调度器(fast and fairscheduler)：为某些任务指定优先级可实现理好的QoS； 会话速率限制(session rate limiting)：适用于托管环境； 注意：1)1.1、1.2、1.3的poll和epoll机制对性能影响 1.1l版本默认使用的polling系统为select()，其处理的文件数达数千个时性能便会急剧下降。 1.2和1.3版本默认的为poll()，在有些操作系统上可会也会有性能方面的问题，但在Solaris上表现相当不错。 HAProxy1.3在Linux 2.6及打了epoll补丁的Linux2.4上默认使用epoll，在FreeBSD上使用kqueue，这两种机制在任何负载上都能提供恒定的性能表现。 2) 高性能选型方案
Linux 2.6.32及之后版本上运行HAProxy 1.4；
打了epoll补丁的Linux2.4上运行HAProxy 1.4；FreeBSD上运行HAProxy1.4；Solaris10上运行HAProxy 1.4；3)splice()调用机制 在较新版本的Linux2.6(>=2.6.27.19)上，HAProxy还能够使用splice()系统调用在接口间无复制地转发任何数据，甚至可以达到10Gbps的性能。
HAProxy安装配置
程序包安装
[root@localhost~]# yum install -y haproxy
主配置文件：/etc/haproxy/haproxy.cfg主程序：/usr/sbin/haproxy配置文件格式
实例一：
frontend main *:5000 acl url_static path_beg -i /static /images /JavaScript/stylesheets acl url_static path_end -i .jpg .gif .png .css .js use_backend static if url_static default_backend appbackendstatic balance roundrobin server static 127.0.0.1:4331 checkbackendapp balance roundrobin server app1 127.0.0.1:5001 check server app2 127.0.0.1:5002 check server app3 127.0.0.1:5003 check server app4 127.0.0.1:5004 check
实例二：
frontendmainbind *:80default_backendwebsrvsbackendwebsrvsbalanceroundrobinserver web1 172.16.49.102:80 checkserver web2 172.16.49.103:80 check
HAProxy代理相关配置
balance
定义负载均衡算法，可用于"defaults"、"listen"和"backend"配置段
① roundrobin，表示简单的轮询，这个是负载均衡基本都具备的； ② static-rr，表示根据权重，选择 server 的逻辑最为简单 ③ leastconn，表示最少连接者先处理 ④ source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，用其作为解决session问题的一种方法 ⑤ ri，表示根据请求的URI； ⑥ rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name； ⑦ hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求； ⑧ rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。
注意
(1)当使用uri算法时，第一次请求一个URL分发到一个主机，则之后再次请求相同URL则使用一台主机响应。当第一次请求之后，若响应该请求的主机服务出现故障，则haproxy或将其调度到其他主机，此主机修复后再次调度回来 (2)URI：统一资源标识符；格式如下：:// : @ : / ; ? # 方案://用户:密码@主机:端口/路径;参数(键值数据、可以多个参数字段)?查询语句#片段显示
hash-type
格式：hash-type定义用于将hash码映射至后端服务器的方法；不能用于frontend区段；可用方法有map-based和consistent 说明：
bind
定义一个或者几个监听的套接字、只能用于frontend， listen; bind[]:[, ...] bind[ ]: [, ...] interface
default_backend
为frontend指明使用的默认后端；default_backend<backend>
实例：use_backend dynamic if url_dynuse_backend static if url_css url_img extension_imgdefault_backend dynamic注意：use_backend: 条件式后端调用；
server
server <name> <addr>:port；用于为后端声明一个server
<name>：名称，标识符<addr>[:port]：设定后端真实服务器监听的端口和地址 [param*]：参数backup: 设定为备用服务器，仅在负载均衡场景中的其它server均不可用于启用此server；check:健康状态检测；inter<delay>：检测时间间隔；单位为ms, 默认为2000;rise<count>：设定健康状态检查中，某离线的server从离线状态转换至正常状态需要成功检查的次数；fall<count>：确认server从正常状态转换为不可用状态需要检查的次数；cookie <value>：为指定server设定cookie值，用于实现持久连接的功能；maxconn:此服务接受的并发连接的最大数量；maxqueue:请求队列的最大长度；observe:根据流量判断后端server的健康状态；weight #: 指定权重，#默认为1，最大为256；0表示不被调度；redir<prefix>: 重定向；所有发往此服务器的请求均以302响应；注意：
健康监测的方式有多种，具体服务可能检测方法的配置指令不同；此处为后端http服务时的健康状态的检测方法，在defaults配置段定义了" option httpchk "。"httpchk"、"smtpchk"、"mysql-check"、"pgsql-check"、"ssl-hello-chk"
实例：基于浏览器cookie实现sessionsticky(会话绑定)
backendwebsrvs
balance roundrobin cookie SERVERID insert # 报文首部插入标识 server web1 172.16.49.102:80 check weight 1 cookie websrv1 # cookie绑定名称参数标识 server web2 172.16.49.103:80 check weight 3 cookie websrv2
注释：每个server有自己惟一的cookie标识、在backend中定义为用户请求调度完成后操纵其cookie
日志记录信息
(1) capture requestheader
格式：capture request headerlen 捕获并记录指定的请求首部最近一次出现时的第一个值，仅能用于“frontend”和“listen”区段 ：要捕获的首部的名称，此名称不区分字符大小写，但建议与它们出现在首部中的格式相同，比如大写首字母。需要注意的是，记录在日志中的是首部对应的值，而非首部名称。 ：指定记录首部值时所记录的精确长度，超出的部分将会被忽略。
注意：
可以捕获的请求首部的个数没有限制，但每个捕获最多只能记录64个字符。为了保证同一个frontend中日志格式的统一性，首部捕获仅能在frontend中定义。
(2)captureresponse header；捕获并记录响应首部，其格式和要点同请求首部。
格式：capture response headerlen
HAProxy状态监控页配置
配置监控页信息
1.配置监控页信息
(1)stats enable启用基于程序编译时默认设置的统计报告，不能用于“frontend”区段。
(2)stats hide-version
启用统计报告并隐藏HAProxy版本报告，不能用于“frontend”区段。
(3)stats realm
格式：stats realm：实现HTTP基本认证时显示在浏览器中的领域名称，用于提示用户输入一个用户名和密码。 启用统计报告并高精认证领域，不能用于“frontend”区段。haproxy在读取realm时会将其视作一个单词，因此，中间的任何空白字符都必须使用反斜线进行转义。此参数仅在与“statsauth”配置使用时有意义。
(4)stats scope
stats scope { | "." } ：可以是“listen”、“frontend”或“backend”区段的名称，而“.”则表示statsscope语句所定义的当前区段。 启用统计报告并限定报告的区段，不能用于“frontend”区段。当指定此语句时，统计报告将仅显示其列举出区段的报告信息，所有其它区段的信息将被隐藏。如果需要显示多个区段的统计报告，此语句可以定义多次。需要注意的是，区段名称检测仅仅是以字符串比较的方式进行，它不会真检测指定的区段是否真正存在。 (5)stats auth
格式：stats auth: ：授权进行访问的用户名； ：此用户的访问密码，明文格式； 启用带认证的统计报告功能并授权一个用户帐号，其不能用于“frontend”区段。
(6)stats admin
格式：stats admin {if | unless } 在指定的条件满足时启用统计报告页面的管理级别功能，它允许通过web接口启用或禁用服务器。 配置案例：stats状态监控页
(1)在配置文件/etc/haproxy/haproxy.cfg中配置代理和监控配置信息
listenstatisticsbind *:9090stats enablestats hide-versionstats uri /haproxyadmin?stats stats realm "HAPorxy\Statistics"stats auth admin:xudingstats admin if TRUE
(2)访问URL：
(3)此时即可进入管理页面进行对后端服务器的管理和页面监控数据监控
说明：
错误页面
errorfile:使用haproxy主机本地文件进行响应；errorloc,errorloc302: 使用指定的url进行响应，响应状态码为302；不适用于GET以外的其它请求方法；errorloc303：返回303状态码；
errorfile
格式：errorfile ：指定对HTTP的哪些状态码返回指定的页面；这里可用的状态码有200、400、403、408、500、502、503和504；<file>：指定用于响应的页面文件
在用户请求不存在的页面时，返回一个页面文件给客户端而非由haproxy生成的错误代码；可用于所有段中。
实例：
errorfile400 /etc/haproxy/errorpages/400badreq.httperrorfile403 /etc/haproxy/errorpages/403forbid.httperrorfile503 /etc/haproxy/errorpages/503sorry.httperrorloc和errorloc302
请求错误时，返回一个HTTP重定向至某URL的信息；可用于所有配置段中。 errorloc errorloc302 ：指定对HTTP的哪些状态码返回指定的页面；这里可用的状态码有200、400、403、408、500、502、503和504； ：Location首部中指定的页面位置的具体路径，可以是在当前服务器上的页面的相对路径，也可以使用绝对路径；需要注意的是，如果URI自身错误时产生某特定状态码信息的话，有可能会导致循环定向； 注意：
这两个关键字都会返回302状态吗，这将使得客户端使用同样的HTTP方法获取指定的URL，对于非GET广场法的场景(如POST)来说会产生问题，因为返回客户的URL是不允许使用GET以外的其它方法的。如果的确有这种问题，可以使用errorloc303来返回303状态码给客户端。
errorloc303
errorloc303 ；请求错误时，返回一个HTTP重定向至某URL的信息给客户端；可用于所有配置段中。 ：指定对HTTP的哪些状态码返回指定的页面；这里可用的状态码有400、403、408、500、502、503和504； ：Location首部中指定的页面位置的具体路径，可以是在当前服务器上的页面的相对路径，也可以使用绝对路径；需要注意的是，如果URI自身错误时产生某特定状态码信息的话，有可能会导致循环定向； 实例：
backendwebserver server 172.16.100.6 172.16.100.6:80 checkmaxconn 3000 cookie srv01 server 172.16.100.7 172.16.100.7:80 checkmaxconn 3000 cookie srv02 errorfile 403/etc/haproxy/errorpages/sorry.htm errorfile 503/etc/haproxy/errorpages/sorry.htm