代理相关配置参数
内容参考自马哥教育
URI Syntax：
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag> //<scheme>表示协议；<user>:<password>可以省略；<params>表示参数；？<query>表示查询字符串；
URI的左半部分是：<scheme>://<user>:<password>@<host>:<port>/<path>;<params>
;<params>
ftp://downloads.dongshi.com/pub/gnu;type=d //type=d就是指明了类型，是一个params
http://www.dongshi.com/hammers;sale=false/index.html;graphics=true //红色部分为params
?<query>
http://www.joes-hardware.com/inventory-check.cgi?item=12741 //?item=12741表示要把item=12741当作查询条件，通过URL(红色部分)把条件发送给服务器端，然后服务器端会把查询条件嵌入到php或jsp的页面程序当中，由这个页面程序基于mysql或者其他存储协议发往服务器端，并由服务器端执行并取回结果，所以?item=12741是查询字符串。
什么情况下可以用到URI算法？(调度方式：对URL做hash计算，将计算结果除以总权重数)
当后端服务器是缓存服务器时特别有用，即无论哪个客户端发出请求，只要资源链接是同一个，haproxy主机都可以始终把请求发送至同一个backend server(缓存服务器)。假如有一个资源链接在之前没有被用户请求过，所以并没有缓存，那么haproxy就会根据后端缓存服务器的权重挑选一个backend server响应用户的请求。一旦根据算法挑选backend server结束，haproxy内部就会维护一个hash表，表中存储的是键值对，键是URL的hash值，值是之前挑选出的对应的backend server的地址，因此如果有客户端再次请求同一个资源链接时，haproxy会把URL做hash计算，对比内部维护的hash表，有相同的键就直接把这个请求发送到键对应的值的backend server中。
URI算法示例（根据请求的URL进行调度）
# vim /etc/haproxy/haproxy.cfg //在代理服务器上进行操作
1 #--------------------------------------------------------------------- 2 # static backend for serving up images, stylesheets and such 3 #--------------------------------------------------------------------- 4 backend websrvs 5 balance uri //使用uri算法 6 hash-type consistent //类型为consistent 7 server web1 192.168.128.132:80 check 8 server web2 192.168.128.133:80 check
# systemctl reload haproxy
# systemctl status haproxy
# for i in {1..10}; do echo "<h1>Page $i on node2" > /var/www/html/test$i.html; done //在node2上添加10个页面
# for i in {1..10}; do echo "<h1>Page $i on node3" > /var/www/html/test$i.html; done //在node3上添加10个页面
从上面的图片可以看出，利用uri算法可以把同一个资源链接始终发送至后端的同一个backend server，无论使用什么样的请求方式。
代理参数：
balance: 指明调度算法；
动态：权重可动态调整
静态：调整权重不会实时生效
roundrobin: 轮询(加权轮询)，动态算法，每个后端主机最多支持4128个连接；
static-rr: 轮询，静态算法，每个后端主机支持的数量无上限；
leastconn: 根据后端主机的负载数量进行调度；仅适用长连接的会话；动态；
source：这种算法有静态和动态两种，取决于hash类型
hash-type:
map-based：取模法；静态；
consistent：一致性哈希法；动态；
uri:
hash-type
map-based:更省资源
consistent:由于服务器总会上下线，所以一般会把hash-type设置为consistent
url_param: 根据url中的指定的参数的值进行调度；把值做hash计算，并除以总权重；
hash-type
map-based:
consistent:
hdr(<name>) ：根据请求报文中指定的header(如use_agent, referer, hostname)进行调度；把指定的header的值做hash计算；
hash-type
map-based:
consistent:
bind：
只能用于frontend, listen;
mode:
HAProxy的工作模式；默认为tcp；
tcp, http, health
log:
maxconn:
default_backend:
为frontend指明使用的默认后端；
use_backend: 条件式后端调用；
K.I.S.S: Keep it simple, stupid.
server:
server <name> <addr>[:port] [param*]
backup: 设定当前server为backup server；
check: 健康状态检测；
inter <delay>：检测时间间隔；单位为ms, 默认为2000;
fall: up --> down, soft state, soft state, hard state;
rise：down --> up,
cookie <value>：
maxconn: 此服务接受的并发连接的最大数量；
maxqueue: 请求队列的最大长度；
observe: 根据流量判断后端server的健康状态；
weight: 指定权重，默认为1，最大为256；0表示不被调度；
redir <prefix>: 重定向；所有发往此服务器的请求均以302响应；
后端http服务时的健康状态的检测方法：
option httpchk
基于浏览器cookie实现session sticky：
backend websrvs
balance roundrobin
cookie SERVERID insert nocache indirect
server web1 172.16.100.68:80 check weight 1 cookie websrv1
server web2 172.16.100.69:80 check weight 3 cookie websrv2
要点：
(1) 每个server有自己惟一的cookie标识；
(2) 在backend中定义为用户请求调度完成后操纵其cookie
启用stats：
listen statistics
bind *:9090
stats enable
stats hide-version
#stats scope .
stats uri /haproxyadmin?stats
stats realm "HAPorxy\ Statistics"
stats auth admin:mageedu
stats admin if TRUE
向日志中记录额外信息：
capture request header
capture response header
当mode为http时，记录丰富的日志信息：
option httplog
错误页面重定向：
errorfile: 使用haproxy主机本地文件进行响应；
errorloc, errorloc302: 使用指定的url进行响应，响应状态码为302；不适用于GET以外的其它请求方法；
errorloc303：返回303状态码；
访问控制：
http_request
tcp_request
添加请求或响应报文首部：
reqadd
rspadd
ACL
定义，及调用；