提示：本文最后更新于2022⑴2⑴6 18:33，文中所关联的信息可能已产生改变，请知悉！

一、HAProxy简介

HAProxy是一种高效、可靠、不要钱的高可用及负载均衡解决方案，非常合适于高负载站点的七层数据要求。（HAProxy可以基于四层和七层提供TCP和HTTP(select mode,根据报文内容)利用的负载均衡综合解决方案。）由于HAProxy实现了一种事件驱动、单一进程模型，此模型支持非常大的并发连接数。
客户端通过HAProxy代理服务器取得站点页面，而代理服务器收到客户要求后根据负载均衡的规则将要求数据转发给后端真实服务器。HAProxy还支持Session的保持和Cookie的引导。

同一客户端访问服务器，HAProxy保持会话的三种方案：

1、 HAProxy将客户端ip进行Hash计算并保存，由此确保相同IP访问时被转发到同一真实服务器上。( 配置：balance source)

2、 HAProxy依托所使用的服务器发送给客户真个cookie信息进行会话保持。

3、 HAProxy保存所使用的服务器的session及服务器标识，实现会话保持功能。

二、HAProxy工作原理

HAProxy有前端（frontend）和后端（backend），前端和后端都可以有多个。也能够只有一个listen块来同时实现前端和后端。这里主要讲一下frontend和backend工作模式。 前端（frontend）区域可以根据HTTP要求的header信息来定义一些规则，然后将符合某规则的要求转发到相应后端（backend）进行处理。因此HAProxy可以实现消息分离（消息分离简单来讲就是指将静态要求转发到对应的静态资源服务器，将动态要求转发到动态资源服务器）

三、HAProxy配置文件

修改haproxy的主配置文件 vim /etc/haproxy/haproxy.cfg（haproxy不处理SSL时，mode应为tcp）

vim /etc/haproxy/haproxy.cfg
#修改内容以下：
frontend  main 
    bind *:80
    default_backend             webservers

backend webservers
    balance     roundrobin
    server  app1 192.168.1.105:80 check
    server  app2 192.168.1.106:80 check

Round Robin算法

轮询调度（Round Robin Scheduling）算法就是以轮询的方式顺次将要求调度区别的服务器，即每次调度履行i = (i + 1) mod n，并选出第i台服务器。
算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。唯一两台服务器的话，会在两台服务器间轮番转发要求。

会话保持的第一种方法：基于source算法，确保相同IP访问时被转发到同一真实服务器上。

Source算法

1）把balance调度算法改成source:
vim /etc/haproxy/haproxy.cfg
backend webservers
        balance source
#自于同一IP的要求，始终定向至同一台

RI(url)算法

1）把balance调度算法改成uri:
vim /etc/haproxy/haproxy.cfg
backend webservers
    balance uri
    server  app1 192.168.1.105:80 check
    server  app2 192.168.1.106:80 check
#uri的机制，对同一个uri(资源)的要求，始终定义至同一个server上。不管从哪一个客户端访问test1.html, 都指向的是web2上面的test1.html；不管从哪一个客户端访问test2.html, 都指向的是web1上面的test2.html,与客户端IP无关，与每一个服务端要求次数无关，与使用的客户端类型无关。

四、HAProxy负载均衡-会话保持

也就是我们在简介中提到的第二种设置会话保持的方法，HAProxy依托真实服务器发送给客户真个cookie信息（也就是浏览器真个缓存信息中会包括服务器的node信息， 如web1 或 是web2， 从而该浏览器下次访问时还会访问之前访问过的web服务器。）进行会话保持。

vim /etc/haproxy/haproxy.cfg
---
backend webserver
  cookie node insert nocache
  stats enable
  server web1 ip1:port check node1
  server web2 ip2:port check node2
--- 
#重载haproxy
systemctl reload haproxy

配置haproxy消息分流

LOADING

配置haproxy域名分流(SNI,Server Name Indication)(SSL)

LOADING

五、HAProxy后端web服务器状态检测(灾备)

HAProxy有三种状态检测方式：
1）.基于四层的传输端口做状态监测
2）.基于指定的uri做状态监测
3）.基于指定的URI的resquest要求头部内容做状态监测

1. 基于四层的传输端口做状态监测

通过监听端口进行健康检测。这类检测方式，haproxy检查后端server的端口，其实不能保证服务的真正可用。有时候服务端口监听和进程都是存在的，不代表正常提供服务，这时候使用基于端口的监听方式明显就不太适合了。

vim /etc/haproxy/haproxy.cfg
#inter 时间间隔 
---
backend webserver
  balance roundrobin
  cookie HAPROXY-COOKIE insert indirect nocache
  server web1 ip1:port check port xx addr ip inter 3000 fail 3 rise 5
  server web2 ip2:port check port xx addr ip inter 3000 fail 3 rise 5
--- 
#重载haproxy
systemctl reload haproxy

2. 基于指定的uri做状态监测

用GET后端server的的web页面，基本上可以代表后端服务的可用性。摹拟客户端去访问服务端，如果响应码是正常的说明服务端处于正常工作状态，避免了基于端口监控的弊端。

vim /etc/haproxy/haproxy.cfg
---
listen webserver
  mode http
  bind *:80
  balance roundrobin
  cookie HAPROXY-COOKIE insert indirect nocache
  option httpchk GET / URI
  server web1 ip1:port check cookie node1 check
  server web2 ip2:port check port xx addr ip inter 3000 fail 3 raise 5
--- 
#重载haproxy
systemctl reload haproxy

3. 基于指定的URI的resquest要求头部内容做状态监测

抛弃消息体(body)部份，只返回给haproxy响应头部(head)信息便可，节省了后端web服务器的网络I/O。

#LOADING

桂>哥>网>络www.guIgege.cn

TikTok千粉号购买平台：https://tiktokusername.com/