HaProxy的负载均衡策略

zuier

　　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