1, Static algorithm

1.1 static-rr

The weight based polling scheduling does not support the dynamic adjustment of the weight by using socat at at runtime (only supports 0 and 1, and does not support other values) and the slow start of the back-end server. The number of back-end hosts is unlimited, which is equivalent to the wrr in LVS.

listen web_host
	bind 10.0.0.7:80
	mode http
	log global
	balance static-rr	
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 2 check inter 3000 fall 2 rise 5

1.2 first

Scheduling is performed from top to bottom according to the location of the server in the list, but the new request will be allocated to the next service only when the number of connections of the first server reaches the upper limit. Therefore, the weight setting of the server will be ignored. This method is less used. Dynamic weight modification with socat is not supported. 0 and 1 can be set, and other values can be set, but they are invalid.

listen web_host
	bind 10.0.0.7:80
	mode http
	log global
	balance first
	server web1 10.0.0.17:80 maxconn 2 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

2, Dynamic algorithm

2.1 roundrobin

The weight based polling dynamic scheduling algorithm supports the runtime adjustment of weight, which is different from the rr rotation training mode in lvs,
The roundrobin in HAProxy supports slow start (the newly added server will gradually increase the number of forwards), and there are at most one in each backend backend
It has 4095 real servers and supports dynamic adjustment of the weight of real servers. roundrobin is the default scheduling algorithm, which is widely used.

listen web_host
	bind 10.0.0.7:80
	mode http
	log global
	balance roundrobin
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 2 check inter 3000 fall 2 rise 5

2.2 leastconn

The least connected dynamic weighted by leastconn supports the runtime adjustment and slow start of the weight, that is, the priority scheduling (new client connection) is based on the back-end server with the least current connection rather than the weight, which is more suitable for long connection scenarios, such as MySQL.

listen web_host
	bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010
	mode http
	log global
	balance leastconn
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

2.3 random

In version 1.9, random's load balancing algorithm is added. It is based on random number as the key of consistency hash. Random load balancing is very useful for large server farms or servers that are often added or deleted. It supports dynamic adjustment of weight, and hosts with larger weight have a more likely rate to obtain new requests.

listen web_host
	bind 10.0.0.7:80
	mode http
	log global
	balance random
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

3, Other algorithms

Other algorithms can be used as static algorithms or dynamic algorithms through options

3.1 source

• The source address hash is based on the user's source address hash and forwards the request to the back-end server. The subsequent request of the same source address will be forwarded to the same back-end web server. In this way, when the data volume of the back-end server changes, many users' requests will be forwarded to the new back-end server. The default mode is static, but it can be changed through the options supported by hash type

• This algorithm is generally used in TCP mode without inserting cookies. It can also provide the best session stickiness for customers who refuse session cookies. It is suitable for scenarios where session is maintained but does not support cookies and caching

• There are two calculation methods of server selection for the source address to forward the client request to the back-end server, which are modulus method and consistency hash

3.1.1 map base modeling method

Map based modulo method, hash the source address, and then modulo based on the total weight of the server. The final result determines to forward the request to the corresponding back-end server. This method is static, that is, it does not support online weight adjustment and slow start, and can realize balanced scheduling of back-end servers. The disadvantage is that when the total weight of the server changes, that is, when the server goes online or offline, the overall scheduling result will change due to the change of the total weight. The default value specified by hash type is this algorithm.

listen web_host
	bind 10.0.0.7:80
	mode tcp
	log global
	balance source
	hash-type map-based	#If it is not written, the default map based static algorithm is used
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 3
	server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 3

3.1.2 consistency hash

Consistent hash: when the total weight of the server changes, the impact on the scheduling result is local and will not cause large changes. Hash (o) mod n, the hash algorithm is dynamic, supports online weight adjustment using socat and other tools, and supports slow start.

listen web_host
	bind 10.0.0.7:80
	mode tcp
	log global
	balance source
	hash-type consistent
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

3.4 uri

Based on hashing the left half or the whole URI of the URI requested by the user, and then taking the total weight of the hash result, according to the final result
Forward the request to the specified server at the back end, which is applicable to the scenario where the back end is a cache server. The default is a static algorithm, or you can use hash type
Specify map based and consistent to define whether to use modulo or consistent hash.

listen web_host
	bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010
	mode http
	log global
	balance uri
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

3.5 url_param

url_param hash es the value value corresponding to a parameter key in the params part of the URL requested by the user, and the value is calculated by the server
Divide the total weight and send it to a selected server; It is usually used to track users to ensure that requests from the same user are always sent to the same user
For a real server, if there is no key, it will follow the roundrobin algorithm

##url_param modular configuration example
listen web_host
	bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010
	mode http
	log global
	balance url_param userid 
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

3.6 hdr

hash the specified information in each http header request of the user. Here, the http header specified by name will be taken out and displayed
Do hash calculation, and then take the model of the total weight of the server and send it to a selected server. If there is no valid value, the default round will be used
Inquire about scheduling.

#hdr module configuration example
listen web_host
	bind 10.0.0.7:80,:8801-8810,10.0.0.7:9001-9010
	mode http
	log global
	balance hdr(User-Agent)
	#balance hdr(host)
	
	server web1 10.0.0.17:80 weight 1 check inter 3000 fall 2 rise 5
	server web2 10.0.0.27:80 weight 1 check inter 3000 fall 2 rise 5

3.7 rdp-cookie

The load of RDP cookies on the remote windows desktop. Use cookies to maintain the session. The default is static, or you can use hash type
Specify map based and consistent to define whether to use modulo or consistent hash.

#RDP cookie modulo configuration example
listen RDP
	bind 10.0.0.7:3389
	balance rdp-cookie
	mode tcp
	server rdp0 10.0.0.17:3389 check fall 3 rise 5 inter 2000 weight 1

4, Use occasion