HAProxy简介及常用配置文件详解见：http://blog.51cto.com/holmes975/2333207
一、HAProxy的动静分离实现实例
我们通过CentOS7.5中的HAProxy实现负载均衡调度功能，将用户发来的请求进行动态静态分离并将请求发送到后端不同的服务器上。三台后端服务器CentOS7.5A、CentOS7.5B、CentOS7.5C上分别开启httpd或nginx服务提供可访问的web端。（haproxy本身是不提供可访问的web页面）
CentOS7.5----HAProxy配置文件：
我定义了一个叫做main的frontend，监听所有IP的80端口，下面写了两条ACL规则，将PATH部分以/static /images /javascript /stylesheets开头的和PATH部分以.jpg .jpeg .gif .png .css .js .txt .html .htm结尾的（-i 不区分大小写的意思）定义到一个叫url_static的规则里。
use_backend static if url_static
default_backend app
如果符合url_static规则就将访问请求发送到叫做static的后端服务器上，默认的后端服务器使用叫做app。
下面分别定义了两个后端服务器static和app。
static：轮询算法调用服务器（一个一个的按顺序的调用所定义的服务器），调度到179.5.99.15:80.
app：使用默认轮询方式调度两台后端服务器app1和app2。
下面进行测试：
向CentOS7.5C静态服务器httpd下创建一个名为index.html内容为7.5A的文件。
向CentOS7.5A动态服务器httpd下创建一个名为sessiontest.php内容为php测试脚本的文件。
向CentOS7.5B动态服务器nginx下添加相同文件。
访问测试：
可见由.html结尾的文件被分配到7.5C服务器上。
而不符合该ACL规则的其他访问被分配到7.5A和7.5B上。证明试验成功，实现了最基本的动静分离，如有特殊情况可自行修改ACL规则实现需要的动静分离。
二、利用cookie实现会话粘性
简单解释会话粘性就是指在执行某种操作时需要与一台后端服务器实现一段时间的定向连接。
根据上面动静分离实验我们对7.5A和7.5B进行实验。
listen stats #关联前端和后端定义一个完整的代理
mode http #设置代理协议
bind 0.0.0.0:8080 #绑定相应的端口
stats enable #开启Haproxy统计状态
stats refresh 30s #统计页面自动刷新时间间隔
stats uri /admin?stats #访问的url
stats realm "welcome to check haproxy stats !" #统计页面认证时提示内容信息
stats auth admin:123456 #设置登录用户和密码
stats admin if TRUE #如果认证通过，则就可以打开stats
以上代码在haproxy的配置文件中（我的是/etc/haproxy/haproxy.cfg），作用是对后端服务器的健康状态检测。一会检验试验是否成功我们会用到。
上图为加入cookie保持的配置文件，详细含义见http://blog.51cto.com/holmes975/2333207
算法我是用leastconn，此算法针对会话保持更为有效，具体含义见上篇博客。
下面我们重启haproxy服务进行测试，测试在访问动态资源时是否为我们分配到同一台服务器而不是每台服务器为我们响应一次。
]# systemctl reload haproxy
无论我们怎么刷新都不会被分配到7.5B上，说明我们的会话粘性起了作用。为证明7.5B服务器并没有被关闭我们使用上面代码提到的状态检测页面；
可以看到我们的app1和app2都在运行状态下，刷新后还是保持在7.5A也就是app1的服务器上，证明我们试验成功。（static也就是静态服务器不用了，所以刚刚我就将它关掉了，可见down掉的服务器呈红色）