HAProxy的调度算法可以大致分为以下几大类： 静态算法：这类算法的调度策略在配置时就已经确定，并且不会随着负载的变化而改变。常见的静态算法有： Round Robin(轮询) Least Connections(最少连接数) Static-Weight(静态权重) Source IP Hash(源IP哈希) URI Hash(URI哈希) URL Parameter(URL参数) 动态算法：这类算法的调度策略会根据后端服务器的状态和负载情况动态调整。它们能够根据服务器的性能自动分配负载。常见的动态算法有： Dynamic-Weight(动态权重) Least Response(最小响应时间) 随机算法：这类算法随机选择一个后端服务器来处理请求，是一种简单的负载均衡策略。 Random(随机)

静态算法

静态算法是指负载均衡中的调度算法在配置时就已经确定，并且在运行过程中不会随着服务器状态或负载的变化而改变。这些算法将请求均匀地分发到后端服务器，无论服务器的状态如何，分发的比例都是固定的。 以下是一些常见的静态算法： Round Robin(轮询)：按照后端服务器列表的顺序依次将请求分发给每个服务器，然后再从头开始。每个服务器依次接收请求，实现负载均衡。适用于后端服务器性能相近的情况。 Static-Weight(静态权重)：手动设置每个后端服务器的权重值。根据权重值来决定每个服务器获得请求的比例。可以根据服务器性能、硬件配置等设置不同的权重，以实现负载均衡。 Source IP Hash(源IP哈希)：根据客户端的IP地址计算哈希值，并将请求分发到对应的服务器。这样，相同IP的请求总是被分发到同一个后端服务器上。 URI Hash(URI哈希)：根据请求的URI(URL)计算哈希值，并将请求分发到对应的服务器。用于确保特定URI的请求总是发送到同一个后端服务器。 URL Parameter(URL参数)：根据请求的URL参数来选择后端服务器。例如，可以根据某个特定的URL参数值来分发请求。

static-rr

Static-Weight(静态权重)

backend web_servers
    mode http
    balance static-rr
    server web1 192.168.1.100:80 weight 5 check
    server web2 192.168.1.101:80 weight 10 check

round robin

backend web_servers
    mode http
    balance roundrobin
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check

Source IP Hash(源IP哈希)：

backend web_servers
    mode http
    balance source
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check

动态算法

动态算法是指在负载均衡过程中根据服务器状态和负载情况动态调整的算法。在 HAProxy 中，有一种动态算法叫做Least Response(最小响应时间)。

Least Response

算法会选择响应时间最短的服务器来处理请求。它会测量后端服务器的响应时间，并将请求分发给响应时间最短的服务器，以确保请求能够尽快获得响应。这使得负载均衡器可以动态地选择性能最好的服务器来处理请求，从而优化整体性能。

backend web_servers
    mode http
    balance leastresponse
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check

Least Connections(最少连接数)：

backend web_servers
    mode http
    balance leastconn
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check

URI Hash(URI哈希)：

backend web_servers
    mode http
    balance uri
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check

URL Parameter(URL参数)：

backend web_servers
    mode http
    balance url_param sid
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check

随机算法

hdr取模法

您可以使用 hdr() 或 req.hdr() 来指定负载均衡算法，并将请求头中的特定值用于负载均衡。下面是一个基于 hdr() 的取模分发的示例配置：

backend web_servers
    mode http
    balance hdr(User-Agent)
    server web1 192.168.1.100:80 check
    server web2 192.168.1.101:80 check
    server web3 192.168.1.102:80 check

rdp-cookie

rdp-cookie 取模法是用于实现 RDP(Remote Desktop Protocol)会话保持的一种负载均衡算法。当客户端使用 RDP 连接到后端服务器时，服务器会返回一个 RDP-cookie 给客户端，用于标识客户端的会话。HAProxy 可以使用这个 RDP-cookie 来实现会话保持，将同一个客户端的请求始终路由到同一个后端服务器上，从而保持会话的连续性。

frontend rdp_frontend
    bind *:3389
    mode tcp
    default_backend rdp_servers

backend rdp_servers
    mode tcp
    balance rdp-cookie
    option tcp-check
    server rdp1 192.168.1.101:3389 check
    server rdp2 192.168.1.102:3389 check

算法总结

static-rr #做了session共享的web集群
roundrobin
random
leastconn #数据库
source #基于客户端公网IP的会话保持
Uri--------------->http #缓存服务器，CDN服务商，蓝汛、百度、阿里云、腾讯
url_param--------->http
hdr #基于客户端请求报文头部做下一步处理

IP透传

4层透传

send-proxy 是HAProxy提供的一种特性，允许HAProxy在传输层(Layer 4)通过PROXY协议将客户端的真实IP地址和端口信息传递给后端服务器，实现4层的IP透传。 当启用了 send-proxy 特性后，客户端连接到HAProxy时，HAProxy会在建立连接后，通过发送一条特殊的PROXY协议报文给后端服务器，携带了客户端的真实IP地址和端口信息。后端服务器收到这个报文后，就能够获得客户端的真实IP地址，而不是HAProxy的IP地址。 这个特性对于需要在后端服务器上获取客户端真实IP地址的情况非常有用，例如用于记录日志或进行访问控制等。 要在HAProxy中启用 send-proxy 特性，需要在后端服务器的配置中添加 send-proxy 选项。同时，在后端服务器上需要开启对PROXY协议报文的识别和处理

backend app_servers
    mode tcp
    balance roundrobin
    server web1 192.168.1.101:80 send-proxy check
    server web2 192.168.1.102:80 send-proxy check
    server web3 192.168.1.103:80 send-proxy check

请注意，启用 send-proxy 特性后，后端服务器需要支持并能正确处理PROXY协议报文。如果后端服务器不支持PROXY协议，可能会导致连接失败或其他问题。确保后端服务器能够正确处理PROXY协议报文，才可以安全地启用该特性。

7层透传

image.png

haproxy 配置：
defaults
option forwardfor
或者：
option forwardfor header X-Forwarded-xxx #自定义传递IP参数,后端web服务器写X-Forwarded-xxx，如
果写option forwardfor则后端服务器web格式为X-Forwarded-For

image.png