HaProxy的负载均衡策略

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