roundrobin Each server is used in turns, according to their weights.
This is the smoothest and fairest algorithm when the server's
processing time remains equally distributed. This algorithm
is dynamic, which means that server weights may be adjusted
on the fly for slow starts for instance. It is limited by
design to 4128 active servers per backend. Note that in some
large farms, when a server becomes up after having been down
for a very short time, it may sometimes take a few hundreds
requests for it to be re-integrated into the farm and start
receiving traffic. This is normal, though very rare. It is
indicated here in case you would have the chance to observe
it, so that you don't worry.
roundrobin:每个server根据权重依次被轮询，
这个算法是动态的，意味着
server的权重可以实时地被调整。对于每个haproxy的backend servers的数目
而言被限制在4128个活跃数目之内。
static-rr Each server is used in turns, according to their weights.
This algorithm is as similar to roundrobin except that it is
static, which means that changing a server's weight on the
fly will have no effect. On the other hand, it has no design
limitation on the number of servers, and when a server goes
up, it is always immediately reintroduced into the farm, once
the full map is recomputed. It also uses slightly less CPU to
run (around -1%).
静态roundrobin(static-rr):跟roundrobin类似，唯一的区别是不可以动态实时
server权重和backend 的server数目没有上限。
leastconn The server with the lowest number of connections receives the
connection. Round-robin is performed within groups of servers
of the same load to ensure that all servers will be used. Use
of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP. This
algorithm is dynamic, which means that server weights may be
adjusted on the fly for slow starts for instance.
最小连接数目负载均衡策略（leastconn）：round-robin适合于各个server负载相同的情况。
最小连接数目算法适合于长时间会话，如LDAP，SQL，TSE，但是并不适合于HTTP短连接的协议。
source The source IP address is hashed and divided by the total
weight of the running servers to designate which server will
receive the request. This ensures that the same client IP
address will always reach the same server as long as no
server goes down or up. If the hash result changes due to the
number of running servers changing, many clients will be
directed to a different server. This algorithm is generally
used in TCP mode where no cookie may be inserted. It may also
be used on the Internet to provide a best-effort stickiness
to clients which refuse session cookies. This algorithm is
static by default, which means that changing a server's
weight on the fly will have no effect, but this can be
changed using "hash-type".
源IP hash散列调度：将源ip地址进行hash，再根据hasn求模或者一致性hash定位到
hash表中的server上。相同的ip地址的请求被分发到同一个server上。但当server的数量变化时，
来自于同一client的请求可能会被分发到不同的server上。这个算法通常用在没有cookie的tcp模式下。
uri The left part of the URI (before the question mark) is hashed
and divided by the total weight of the running servers. The
result designates which server will receive the request. This
ensures that a same URI will always be directed to the same
server as long as no server goes up or down. This is used
with proxy caches and anti-virus proxies in order to maximize
the cache hit rate. Note that this algorithm may only be used
in an HTTP backend. This algorithm is static by default,
which means that changing a server's weight on the fly will
have no effect, but this can be changed using "hash-type".
This algorithm support two optional parameters "len" and
"depth", both followed by a positive integer number. These
options may be helpful when it is needed to balance servers
based on the beginning of the URI only. The "len" parameter
indicates that the algorithm should only consider that many
characters at the beginning of the URI to compute the hash.
Note that having "len" set to 1 rarely makes sense since most
URIs start with a leading "/".
The "depth" parameter indicates the maximum directory depth
to be used to compute the hash. One level is counted for each
slash in the request. If both parameters are specified, the
evaluation stops when either is reached.
url_param The URL parameter specified in argument will be looked up in
the query string of each HTTP GET request.
If the modifier "check_post" is used, then an HTTP POST
request entity will be searched for the parameter argument,
when it is not found in a query string after a question mark
('?') in the URL. Optionally, specify a number of octets to
wait for before attempting to search the message body. If the
entity can not be searched, then round robin is used for each
request. For instance, if your clients always send the LB
parameter in the first 128 bytes, then specify that. The
default is 48. The entity data will not be scanned until the
required number of octets have arrived at the gateway, this
is the minimum of: (default/max_wait, Content-Length or first
chunk length). If Content-Length is missing or zero, it does
not need to wait for more data than the client promised to
send. When Content-Length is present and larger than
<max_wait>, then waiting is limited to <max_wait> and it is
assumed that this will be enough data to search for the
presence of the parameter. In the unlikely event that
Transfer-Encoding: chunked is used, only the first chunk is
scanned. Parameter values separated by a chunk boundary, may
be randomly balanced if at all.
If the parameter is found followed by an equal sign ('=') and
a value, then the value is hashed and divided by the total
weight of the running servers. The result designates which
server will receive the request.
This is used to track user identifiers in requests and ensure
that a same user ID will always be sent to the same server as
long as no server goes up or down. If no value is found or if
the parameter is not found, then a round robin algorithm is
applied. Note that this algorithm may only be used in an HTTP
backend. This algorithm is static by default, which means
that changing a server's weight on the fly will have no
effect, but this can be changed using "hash-type".
hdr(name) The HTTP header <name> will be looked up in each HTTP request.
Just as with the equivalent ACL 'hdr()' function, the header
name in parenthesis is not case sensitive. If the header is
absent or if it does not contain any value, the roundrobin
algorithm is applied instead.
An optional 'use_domain_only' parameter is available, for
reducing the hash algorithm to the main domain part with some
specific headers such as 'Host'. For instance, in the Host
value "
haproxy.1wt.eu ", only "1wt" will be considered.
This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed using "hash-type".
rdp-cookie
rdp-cookie(name)
The RDP cookie <name> (or "mstshash" if omitted) will be
looked up and hashed for each incoming TCP request. Just as
with the equivalent ACL 'req_rdp_cookie()' function, the name
is not case-sensitive. This mechanism is useful as a degraded
persistence mode, as it makes it possible to always send the
same user (or the same session ID) to the same server. If the
cookie is not found, the normal roundrobin algorithm is
used instead.
Note that for this to work, the frontend must ensure that an
RDP cookie is already present in the request buffer. For this
you must use 'tcp-request content accept' rule combined with
a 'req_rdp_cookie_cnt' ACL.
This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed us