HAProxy是一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于TCP和HTTP的应用程序代理。

HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。

HAProxy实现了一种事件驱动**, **单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户空间(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

包括 GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter和 Tuenti在内的知名网站，及亚马逊网络服务系统都使用了HAProxy。

负载均衡

二层负载均衡（Mac）

用于虚拟mac地址方式，外部对虚拟mac地址请求，负载均衡接收后分配给后端实际的mac地址相应。

三层负载均衡（IP）

一般用于虚拟ip地址的方式，外部对虚拟IP地址请求，负载均衡接收后分配给后端实际的的IP地址相应。

四层负载均衡（Tcp）

在三层负载均衡的基础上，用IP+Port接收请求，再转发到对应的机器上。

七层负载均衡（Http）

根据虚拟的url或者IP，主机名接收请求，再转发到相应的处理服务器上。

实验图：

利用haproxy实现web服务器的代理及高可用，负载均衡；

实验主机：101 102 103 104

101：haproxy服务器

102：web01

103：web02

104：客户端进行测试

首先配置两台web服务器，这里采用源码包的方式进行安装nginx；因为两个网站的步骤大致一样，就是测试文件不一样；

开启同步会话；仅限102 103

安装编译环境及用到的工具；

再创建程序用户并指定登录shell；

将源码包拉到两个服务器开始解压等操作；

cd到解压目录开始配置；

./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module

然后编译及编译后安装；

命令优化；

然后取消同步会话功能；创建各自的测试文件；

然后关闭两个服务器的防火墙及内核安全机制；

检查配置文件语句是否有错误，然后开启该服务，并进行查询；

开始配置haproxy；

先关闭防护墙及内核安全机制；

安装编译环境；

把压缩包拉进去开始解压及编译；

解压后cd到解压目录开始编译，且编译的时候需要指定内核的版本；

然后编译后安装；make install

建立haproxy的配置文件；

然后创建服务脚本；

给这个系统管理脚本一个执行权；并设置成系统服务；

修改haproxy的配置文件；

把listen模块的删除掉，自己写语句；

补充：里面的单位都是毫秒；1秒等于1000毫秒；

语句解释：

各个语句的解释

global

        log 127.0.0.1   local0     \\配置日志记录，local0为日志设备，默认是系统日志

        log 127.0.0.1   local1 notice      \\日志级别为notice

        #log loghost    local0 info    

        maxconn 4096       \\最大连接数

        uid 99           \\用户uid

        gid 99           \\用户gid

        daemon        \\以守护进程的方式运行

        #debug      \\调试模式，输出启动信息到标准输出

        #quiet     \\安静模式，启动时无输出

defaults

        log     global           \\使用globle中定义的日志

        mode    http           \\模式为http

        option  httplog         \\采用http的格式记录日志

        option  dontlognull     \\保证HAProxy不记录上级负载均衡发送过来的用于检测状态数据的心跳包

        retries 3             \\检查节点连接失败的次数，超过3次认为节点不可用

       # redispatch         \\当负载很高时，自动结束当前队列处理比较久的连接

        maxconn 2000      \\最大连接数

        contimeout      5000         \\连接超时时间ms

        clitimeout      50000        客户端超时时间ms

        srvtimeout      50000              服务器超时时间ms

listen  webcluster 0.0.0.0:80        \\定义群集和监听的端口号

        option  httpchk GET /index.html    \\检查服务器的index.html文件，心跳检测URL设置

        balance roundrobin      \\负载均衡的调度算法为轮询

        server  inst1 192.168.1.61:80 check inter 2000 fall 3        \\定义在线节点

        server  inst2 192.168.1.62:80 check inter 2000 fall 3          

check inter 2000是检测心跳频率（每2000ms检测一次），fall 3是3次失败认为服务器不可用

在新版本中，超时的设置做了调整，具体如下

contimeout 被 timeout connect取代：定义haproxy将客户端请求转发至后端服务器所等待的超时时长

clitimeout 被timeout client取代：客户端非活动状态的超时时长，是 app 连接 haproxy的时间  

srvtimeout 被timeout server取代：客户端与服务器端建立连接后，等待服务器端的超时时长，是haproxy 连接后端web服务器的时间.

注释：

haproxy共有八种调度算法

1) balance leastconn   最少连接数

2) balance roundrobin  轮询

3) balance source      根据客户端IP进行哈希的方式

4) static-rr    根据权重

5) uri    根据请求的URI

6) url_param    根据请求的URl参数

7) hdr(name)   根据HTTP请求头来锁定每一次HTTP请求

8) rdp-cookie(name)   根据cookie(name)来锁定并哈希每一次TCP请求

chroot /usr/share/haproxy  \\也就是改变程序执行时所参考的根目录位置，如果有此代码，需要创建此目录

关于日志级别

static Level DEBUG

DEBUG Level指出细粒度信息事件对调试应用程序是非常有帮助的。

static Level INFO

INFO level表明 消息在粗粒度级别上突出强调应用程序的运行过程。

static Level WARN

WARN level表明会出现潜在错误的情形。

static Level ERROR

ERROR level指出虽然发生错误事件，但仍然不影响系统的继续运行。

static Level FATAL

FATAL level指出每个严重的错误事件将会导致应用程序的退出。

另外，还有两个可用的特别的日志记录级别:

static Level ALL

ALL Level是最低等级的，用于打开所有日志记录。

static Level OFF

OFF Level是最高等级的，用于关闭所有日志记录。

启动该服务；

再开启另外的客户机进行测试；104

对于haporxy的日志进行设置；

添加lcoal3的语句；

编写haproxy日志文件；

注释：

$ModLoad imudp   采集日志的协议UDP

$UDPServerRun 514    指定日志采集使用的端口号

local3.*     /var/log/haproxy.log   指定日志存放位置

最后重启采集日志的服务（rsyslog）及haproxy服务；

再用客户机进行试验；并检查haproxy上的日志文件中有没有采集到信息；