Haproxy配置项及配置实例-Haproxy入门教程

Haproxy配置项及配置实例-Haproxy⼊门教程
常⽤配置选项：
OPTION 选项：
option httpclose ：HAProxy会针对客户端的第⼀条请求的返回添加cookie并返回给客户端，客户端发送后续请求时会发送此cookie到HAProxy，HAProxy会针对此cookie分发到上次处理此请求的服务器上，如果服务器不能忽略
此cookie值会影响处理结果。

如果避免这种情况配置此选项，防⽌产⽣多余的cookie信息。

option forwardfor ：如果服务器上的应⽤程序想记录发起请求的客户端的IP地址，需要在HAProxy上配置此选项，这样
HAProxy会把客户端的IP信息发送给服务器，在HTTP请求中添加"X-Forwarded-For"字段。

option originalto ：如果服务器上的应⽤程序想记录发起请求的原⽬的IP地址，需要在HAProxy上配置此选项，这样HAProxy 会添加"X-Original-To"字段。

option dontlognull ：保证HAProxy不记录上级负载均衡发送过来的⽤于检测状态没有数据的⼼跳包。

BALANCE 选项：
balance source ：如果想让HAProxy按照客户端的IP地址进⾏负载均衡策略，即同⼀IP地址的所有请求都发送到同⼀服务
器时，需要配置此选项。

balance roundrobin ：HAProxy把请求轮流的转发到每⼀个服务器上，依据每台服务器的权重，此权重会动态调整。

最常
见的默认配置。

COOKIE 选项：
cookie JSESSIONID prefix ：如果客户端只⽀持⼀个cookie，并且服务器上的应⽤程序已经对返回设置了cookie，
HAProxy设置此选项可以改写应⽤程序设置的cookie信息，把服务器的信息添加到原cookie中去。

cookie SERVERID indirect ：HAProxy会删除添加的cookie信息，避免此cookie信息发送到服务器。

cookie SERVERID rewrite ：
cookie SERVERID insert ：
cookie SERVERID insert nocache ：
cookie SERVERID insert postonly ：
option httpclose
no option httpclose
Enable or disable passive HTTP connection closing 启⽤或禁⽌消极的HTTP连接关闭
May be used in sections : defaults | frontend | listen | backend
yes | yes | yes | yes
Arguments : none
默认的，客户端与服务端的通讯，HAProxy只做分析、⽇志和分析每个连接的第⼀个request。

如果设置了 "option
httpclose" , 则会检查双向的http头是否有"Connection: close"，如果没有则⾃动添加，使每个客户端或服务端在每次传输后，都会主动关闭TCP连接，使HTTP传输处于HTTP close模式下。

任何 "Connection" 头如果不是"close"，都会被移除。

很少会有服务器不正确的忽略掉头，即使收到"Connection: close"也不关闭连接，否则就是不兼容HTTP 1.0浏览器标准。

如果发⽣这种情况，可以使⽤"option forceclose"，在服务端响应后主动关闭请求连接。

选项 "forceclose"还可以及早释放服务连接，⽽不必等到客户端的应答确认。

这个选项可以设置在frontend或backend上，只要其上可以建⽴连接。

如果同时设置了"option forceclose"，那么它⽐"httpclose"优先。

如果同时设置了 "option http-server-close"，则会实现"option forceclose"的效果。

option forceclose
no option forceclose
Enable or disable active connection closing after response is transferred. 启⽤或禁⽌response后的主动关闭连接
May be used in sections : defaults | frontend | listen | backend
yes | yes | yes | yes
Arguments : none
有的HTTP服务器收到"option httpclose"设置的"Connection: close"，也不会关闭连接，如果客户端也不关闭，连接会⼀直打开，直到超时。

这会造成服务器上同⼀时段内的⼤量连接，⽇志中也会显⽰较⾼的全局会话时间。

此时，可以使⽤ "option forceclose"，当完成响应时，⽴即关闭对外的服务通道。

该选项隐式打开httpclose选项。

需要注意，该选项允许解析完整的request 和 response，所以可以很快关闭⾄服务器的连接，⽐httpclose更早释放⼀些资源。

如果同时启⽤了"option http-pretend-keepalive"，虽然会禁⽌发送 "Connection: close"头，但是依然会在整个response被接收后，关闭连接。

option http-server-close
no option http-server-close
Enable or disable HTTP connection closing on the server side 启⽤或禁⽌关闭服务端的HTTP连接
May be used in sections : defaults | frontend | listen | backend
yes | yes | yes | yes
Arguments : none
默认的，客户端与服务端通讯，haproxy 只是分析、记⽇志，并处理每个连接的第⼀个请求。

该选项设置server端为HTTP 连接关闭模式，并⽀持客户端为HTTP keep-alive的pipelining模式。

提供了最低的客户端延迟和最快的服务端会话重⽤，以节省服务资源，类似"option forceclose"。

还允许⽆keepalive能⼒的服务端在keep-alive模式下为客户端提供服务，但是需要符合 RFC2616。

需要注意的是，有些服务器遇到"Connection: close" 时并不总是执⾏关闭，那么keep-alive 则⽆法使⽤，解决⽅法是启⽤ "option http-pretend-keepalive".
⽬前，⽇志⽆法指明请求是否来⾃同⼀会话；⽇志中的接收⽇期为前⼀个请求的结束；请求时间为新请求的等待时间；keep-alive request time 存活请求时间为超时时间，绑定 "timeout http-keep-alive" 或 "timeout http-request"的设置。

这个操作可以设置在frontend或backend上，只要其上可以建⽴连接。

需要注意的是，这个选项可以与 "option httpclose"结合, 但 "option httpclose"优先级更⾼，结合后基本实现了forceclose的效果。

option http-pretend-keepalive （http-假装-长连接）
no option http-pretend-keepalive
Define whether haproxy will announce keepalive to the server or not 定义 haproxy 与服务器是否是 keepalive 的。

May be used in sections : defaults | frontend | listen | backend
yes | yes | yes | yes
Arguments : none
当声明了 "option http-server-close" 或 "option forceclose", haproxy会在给server的request头中添加 "Connection: close" 。

然⽽有些服务器看到这个头，会返回未知长度的response，并⾃动避免chunked encoding，其实这是不对的。

它会阻⽌haproxy保持客户端长连接，还会使客户端或缓存接收了未完成的响应，却认为响应结束了。

设置 "option http-pretend-keepalive"， haproxy会在服务器端保持长连接，服务端则不会出现前⾯的问题。

当 haproxy 获取了完整的response, 才会以类似forceclose的⽅式关闭服务端。

这样客户端得到⼀个普通的响应，连接也在服务端被正常关闭。

建议不将其设为默认值，因为⼤部分服务器会在发送完最后⼀个包之后更⾼效的关闭连接，并释放缓存，⽽且⽹络上的数据包也会略微降低整体的峰值性能。

但是启⽤该选项，haproxy会略微少做⼀些⼯作。

所以如果haproxy在整个架构中是个瓶颈，可以启⽤该操作，以节省CPU。

这个选项可以设置在frontend或backend上，只要其上可以建⽴连接。

这个选项可以与 "option httpclose"结合, 使服务端keepalive，客户端close，但并不建议这样做。

balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post [<max_wait>]]
定义选择后端服务的负载均衡算法
May be used in sections : defaults | frontend | listen | backend
yes | no | yes | yes
Arguments :
<algorithm> 是负载均衡时选择服务器的算法，没有持续信息时可⽤，或连接重定向到另⼀个服务器。

<algorithm> 可以是以下⼏种：
roundrobin 每个服务器根据权重轮流使⽤，如果服务器的处理时间平均分布，这是最流畅和公平的算法。

算法是动态的，对于实例启动慢的服务器的权重会在运⾏中调整。

每个backend的活动服务器在设计上限制为4128个。

在⼀些⼤的群⾥⾯，当服务器很短的宕机后恢复回来，有时会有⼏百个请求被重新整合到群当中，并开始接收处理。

尽管很少发⽣，但是很正常。

这也说明了有机会监视它们，所以不必担⼼。

static-rr 每个服务器根据权重轮流使⽤，类似roundrobin，但它是静态的，意味着运⾏时修改权重是⽆效的。

另⼀⽅⾯，它对服务器的数量没有设计上的限制，服务器启动后便会⽴即进到群中，整个分发⽅案会重新计算。

这会略微降低CPU的运⾏（约1%）。

leastconn 连接数最低的服务器优先接收连接。

Round-robin⽤于负载相同的服务器，使每台服务器都被使⽤。

leastconn建议⽤于长会话
服务，例如LDAP, SQL, TSE等，⽽不是很适合短会话协议，如HTTP。

算法是动态的，对于实例启动慢的服务器的权重会在运⾏中调整。

source 对源IP地址进⾏哈希，⽤可⽤服务器的权重总数除以哈希值，根据结果进⾏分配。

只要服务器正常，同⼀个客户端IP地址总是访问同⼀台服务器。

如果哈希的结果随可⽤服务器数量⽽变化，那么有的客户端会定向到不同的服务器。

该算法⼀般⽤于不能插⼊cookie的TCP模式。

它还可以⽤于⼴域⽹上，为拒绝使⽤会话cookie的客户端提供最有效的粘连。

该算法默认是静态的，所以运⾏时修改服务器的权重是⽆效的，但是算法会根据"hash-type"的变化做调整。

uri 对URI左端(问号之前)进⾏哈希，⽤可⽤服务器的权重总数除以哈希值，根据结果进⾏分配。

只要服务器正常，同⼀个URI地址总是访问同⼀台服务器。

⼀般⽤于代理缓存和反病毒代理，以最⼤限度的提⾼缓存的命中率。

该算法只能⽤于HTTP后端。

该算法默认是静态的，所以运⾏时修改服务器的权重是⽆效的，但是算法会根据"hash-type"的变化做调整。

算法⽀持两个可选参数"len" 和 "depth"，都是后跟正整数。

“len”参数指定算法只处理URI从头开始的字符数，据此计算哈希。

因为⼤多URI以"/"开头，所以"len"最好不要设为1。

"depth" 参数指定URI中最⼤的路径深度，据此计算哈希。

请求中的每个斜线为⼀级。

如果同时声明了这两个参数，则截取URI时必须同时满⾜。

url_param 在HTTP GET请求的查询串中查找<param>中指定的URL参数。

若使⽤了修饰符"check_post"，如果在URL问号('?')后⾯的查询串中找不到参数，就会搜索HTTP POST 请求实体。

或者在指定的⼀些字节后⾯尝试搜索消息体。

如果搜索不到实体，则使⽤round robin算法。

例如，假设客户端总是在前128个字节发送LB参数，就可以指定它。

默认为48。

如果到达⽹关的字节数量不够，实体数据是检索不到的，⾄少有：（default/max_wait, Content-Length or first chunk length）。

如果Content-Length没有或为0，就不需要等待客户端发送更多的数据。

当Content-Length有值且⼤于<max_wait>，则等待仅限于<max_wait>，并假设有⾜够的数据⽤于搜索参数的存在。

万⼀Transfer-Encoding被⽤了，则只能检查第⼀个块。

如果参数值被块边界分隔开，则只能随机均衡负载了。

如果参数后⾯跟着 ('=') 和⼀个值，则可以根据这个值进⾏哈希，⽤可⽤服务器的权重总数除以哈希值，根据结果进⾏分配。

还可⽤于跟踪请求中的⽤户⾝份，只要服务器正常，同⼀个⽤户ID的请求总是发给同⼀台服务器。

如果没有参数或参数没有值，则使⽤轮询算法。

该算法只⽤于HTTP后端。

该算法默认是静态的，所以运⾏时修改服务器的权重是⽆效的，但是算法会根据"hash-type"的变化做调整。

hdr(name) 在每个HTTP请求中查找HTTP头<name>。

与ACL函数'hdr()'⼀样。

括号括起来的头名字不区分⼤⼩写。

如果缺少头或头没有任何值，则使⽤roundrobin算法代替。

启⽤参数'use_domain_only'，哈希算法将只⽤于⼀些类似'Host'的特定头的主域部分。

例如主机值"haproxy.1wt.eu"，则只考虑"1wt"。

该算法默认是静态的，所以运⾏时修改服务器的权重是⽆效的，但是算法会根据"hash-type"的变化做调整。

rdp-cookie
rdp-cookie(name)
为每个进来的TCP请求查询并哈希RDP cookie <name> (或“mstshash”如果省略) 。

与ACL函数 'req_rdp_cookie()'⼀样，name不区分⼤⼩写。

该机制⽤于退化的持久模式，可以使同⼀个⽤户（或同⼀个会话ID）总是发送给同⼀台服务器。

如果没有cookie，则使⽤roundrobin算法代替。

必须注意该声明要⽣效，前端必须确保在请求缓冲中已经有RDP cookie，所以必须使⽤规则tcp-request content accept' 和ACL 'req_rdp_cookie_cnt'相结合。

该算法默认是静态的，所以运⾏时修改服务器的权重是⽆效的，但是算法会根据"hash-type"的变化做调整。

<arguments> 是⽤于⼀些算法的可选参数列表，⽬前只有"url_param" 和 "uri" ⽤到，例如：
balance uri [len <len>] [depth <depth>]
balance url_param <param> [check_post [<max_wait>]]
如果没有其他算法、模式或选项的设置，后端的负载均衡算法默认为roundrobin。

每个后端只能设置⼀种。

Examples :
balance roundrobin
balance url_param userid
balance url_param session_id check_post 64
balance hdr(User-Agent)
balance hdr(host)
balance hdr(Host) use_domain_only
注意: 以下的警告和限制是使⽤“check_post“扩展和”url_param”所必须考虑：
- 所有POST请求都要考虑，因为在包含⼆进制数据的体或实体中，没有办法决定是否会找到参数。

因此需要另⼀种⽅法，限制POST请求的体中不含有URL参数 (见 acl reqideny http_end)
- ⼤于请求缓冲⼤⼩的 <max_wait> 值是没⽤的。

在build时设置缓冲⼤⼩，默认16KB。

- 不⽀持Content-Encoding, 参数搜索会失败；负载均衡会改⽤ Round Robin。

- 预计: 不⽀持100-continue,负载均衡会改⽤ Round Robin。

- Transfer-Encoding (RFC2616 3.6.1) 只在第⼀个块中⽀持。

如果在第⼀个块中的参数值不完整，选择的服务器就没有定义。

（实际上取决于在第⼀个块中定义的有多⼩）
- 该特性不⽀持⽣成100, 411 或 501 响应。

- 有的情况下，需要"check_post"只是要查看整个消息体的内容。

检查⼀般会停在任意数量的空格（LWS: linear
white space）或控制符上，表⽰这可能是⼀个URL参数列表。

这可能不是⼀个关于SGML的类型消息体。

See also : "dispatch", "cookie", "appsession", "transparent", "hash-type" and "http_proxy".
hash-type <method>
将哈希映射到服务器的⽅法。

Specify a method to use for mapping hashes to servers
May be used in sections : defaults | frontend | listen | backend
yes | no | yes | yes
Arguments :
map-based 哈希表是包含所有在线服务器的静态数组。

哈希结果很平滑，并考虑了权重，但是会忽略服务器启动时的权重变化，也就是说不能慢启动。

另外，服务器是根据数组中的位置所选择的，所以服务器数量变化时，⼤部分映射也会变化。

当⼀台服务器启动或关闭，或服务器加⼊到群中，⼤部分连接会再分配给不同的服务器，这对有缓存的实例会⽐较⿇烦。

consistent 哈希表是由每个服务器构成的树，会在树上查找哈希Key，并选择最近的服务器。

这种哈希是动态的，⽀持服务器启动时修改权重，所以可以慢启动。

它有⼀个好处是当服务器启动或关闭时，只有其本⾝的关系被移除，当服务器加⼊群时，只有⼀⼩部分的映射会被重新分配，所以是⼀个⽐较理想的⽀持缓存的算法。

但是根据其原理，算法不会⾮常平滑，有时候必须调整服务器的权重或ID来获得更平衡的分布。

要保持多次负载均衡时的相同分布，服务器ID是绝对不能变的。

（roloand:haproxy根据服务器的ID初始化其哈希值）
默认值是"map-based"，建议⼤部分情况下使⽤。

See also : "balance", "server"
dispatch <address>:<port>
设置⼀个默认的服务器地址
May be used in sections : defaults | frontend | listen | backend
no | no | yes | yes
Arguments : none
<address> 默认服务器的IPv4地址，也可以是主机名称，名称只在启动时解析为IP地址。

<ports> 端⼝号，所有连接都会发送给这个端⼝，但是不允许像其他服务器⼀样使⽤端⼝偏移（port offsets）。

"dispatch"关键字指定了⼀个默认的服务器，⽤于⽆可⽤服务器时的连接的处理。

过去常⽤于前传⾮持久连接给后备负载均衡器，由于定义简单，还⽤于简单的TCP中继（TCP relays）。

建议对于明确的连接处理，应使⽤"server"直接声明。

====================
====================
HAProxy的配置⽰例
HAProxy配置中分成五部分内容，当然这些组件不是必选的，可以根据需要选择部分作为配置。

global：参数是进程级的，通常和操作系统（OS）相关。

这些参数⼀般只设置⼀次，如果配置⽆误，就不需要再次配置进⾏修改defaults：配置默认参数的，这些参数可以被利⽤配置到frontend，backend，listen组件
frontend：接收请求的前端虚拟节点，Frontend可以根据规则直接指定具体使⽤后端的 backend(可动态选择)。

backend：后端服务集群的配置，是真实的服务器，⼀个Backend对应⼀个或者多个实体服务器。

listen：Frontend和Backend的组合体。

配置具体实例，后附说明：
global
#全局的⽇志配置其中⽇志级别是[err warning info debug]
#local0 是⽇志设备，必须为如下24种标准syslog设备的⼀种:
#kern user mail daemon auth syslog lpr news
#uucp cron auth2 ftp ntp audit alert cron2
#local0 local1 local2 local3 local4 local5 local6 local7
#但是之前在/etc/syslog.conf⽂件中定义的是local0所以
#这⾥也是⽤local0
log 127.0.0.1 local0 info #[err warning info debug]
#最⼤连接数
maxconn 4096
#⽤户
user admin
#组
group admin
#使HAProxy进程进⼊后台运⾏。

这是推荐的运⾏模式
daemon
#创建4个进程进⼊deamon模式运⾏。

此参数要求将运⾏模式设置为"daemon"
nbproc 4
#将所有进程的pid写⼊⽂件启动进程的⽤户必须有权限访问此⽂件。

pidfile /home/admin/haproxy/logs/haproxy.pid
defaults
#默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK
mode http
#采⽤http⽇志格式
option httplog
#三次连接失败就认为是服务器不可⽤，也可以通过后⾯设置
retries 3
如果cookie写⼊了serverId⽽客户端不会刷新cookie，
#当serverId对应的服务器挂掉后，强制定向到其他健康的服务器
option redispatch
#当服务器负载很⾼的时候，⾃动结束掉当前队列处理⽐较久的链接
option abortonclose
#默认的最⼤连接数
maxconn 4096
#连接超时
contimeout 5000
#客户端超时
clitimeout 30000
#服务器超时
srvtimeout 30000
#=⼼跳检测超时
timeout check 2000
#注：⼀些参数值为时间，⽐如说timeout。

时间值通常单位为毫秒(ms)，但是也可以通过加#后缀，来使⽤其他的单位。

#- us : microseconds. 1 microsecond = 1/1000000 second
#- ms : milliseconds. 1 millisecond = 1/1000 second. This is the default.
#- s : seconds. 1s = 1000ms
#- m : minutes. 1m = 60s = 60000ms
#- h : hours. 1h = 60m = 3600s = 3600000ms
#- d : days. 1d = 24h = 1440m = 86400s = 86400000ms
########统计页⾯配置############
listen admin_stats
#监听端⼝
bind 0.0.0.0:1080
#http的7层模式
mode http
#⽇志设置
log 127.0.0.1 local0 err #[err warning info debug]
#统计页⾯⾃动刷新时间
stats refresh 30s
#统计页⾯url
stats uri /admin?stats
#统计页⾯密码框上提⽰⽂本
stats realm Gemini\ Haproxy
#统计页⾯⽤户名和密码设置
stats auth admin:admin
stats auth admin1:admin1
#隐藏统计页⾯上HAProxy的版本信息
stats hide-version
#######⽹站检测listen定义############
listen site_status
bind 0.0.0.0:1081
mode http
log 127.0.0.1 local0 err #[err warning info debug]
#⽹站健康检测URL，⽤来检测HAProxy管理的⽹站是否可以⽤，正常返回200，不正常返回500 monitor-uri /site_status
#定义⽹站down时的策略
#当挂在负载均衡上的指定backend的中有效机器数⼩于1台时返回true
acl site_dead nbsrv(denali_server) lt 1
acl site_dead nbsrv(tm_server) lt 1
acl site_dead nbsrv(mms_server) lt 1
#当满⾜策略的时候返回500
monitor fail if site_dead
#如果192.168.0.252或者192.168.0.31这两天机器挂了
#认为⽹站挂了，这时候返回500，判断标准是如果mode是
#http返回200认为是正常的，如果mode是tcp认为端⼝畅通是好的
monitor-net 192.168.0.252/31
########frontend配置############
frontend http_80_in
#监听端⼝
bind 0.0.0.0:80
#http的7层模式
mode http
#应⽤全局的⽇志配置
log global
#启⽤http的log
option httplog
#每次请求完毕后主动关闭http通道，HA-Proxy不⽀持keep-alive模式
option httpclose
#如果后端服务器需要获得客户端的真实IP需要配置次参数，将可以从Http Header中
#获得客户端IP
option forwardfor
###########HAProxy的⽇志记录内容配置##########
capture request header Host len 40
capture request header Content-Length len 10
capture request header Referer len 200
capture response header Server len 40
capture response header Content-Length len 10
capture response header Cache-Control len 8
####################acl策略定义#########################
#如果请求的满⾜正则表达式返回true -i是忽略⼤⼩写
acl denali_policy hdr_reg(host) -i ^(||)$
#如果请求域名满⾜ 返回 true -i是忽略⼤⼩写
acl tm_policy hdr_dom(host) -i
##在请求url中包含sip_apiname=，则此控制策略返回true,否则为false
acl invalid_req url_sub -i sip_apiname=
##在请求url中存在timetask作为部分地址路径，则此控制策略返回true,否则返回false
acl timetask_req url_dir -i timetask
#当请求的header中Content-length等于0时返回 true
acl missing_cl hdr_cnt(Content-length) eq 0
######################acl策略匹配相应###################
##当请求中header中Content-length等于0 阻⽌请求返回403
block if missing_cl
##block表⽰阻⽌请求，返回403错误，当前表⽰如果不满⾜策略invalid_req，或者满⾜策略timetask_req，则阻⽌请求。

block if !invalid_req || timetask_req
#当满⾜denali_policy的策略时使⽤denali_server的backend
use_backend denali_server if denali_policy
#当满⾜tm_policy的策略时使⽤tm_server的backend
use_backend tm_server if tm_policy
#reqisetbe关键字定义，根据定义的关键字选择backend
reqisetbe ^Host:\ img dynamic
reqisetbe ^[^\ ]*\ /(img|css)/ dynamic
reqisetbe ^[^\ ]*\ /admin/stats stats
#以上都不满⾜的时候使⽤默认mms_server的backend
default_backend mms_server
#HAProxy错误页⾯设置
errorfile 400 /home/admin/haproxy/errorfiles/400.http
errorfile 403 /home/admin/haproxy/errorfiles/403.http
errorfile 408 /home/admin/haproxy/errorfiles/408.http
errorfile 500 /home/admin/haproxy/errorfiles/500.http
errorfile 502 /home/admin/haproxy/errorfiles/502.http
errorfile 503 /home/admin/haproxy/errorfiles/503.http
errorfile 504 /home/admin/haproxy/errorfiles/504.http
##########backend的设置##############
backend mms_server
#http的7层模式
mode http
#负载均衡的⽅式，roundrobin平均⽅式
balance roundrobin
#允许插⼊serverid到cookie中，serverid后⾯可以定义
cookie SERVERID
#⼼跳检测的URL,HTTP/1.1¥r¥nHost:XXXX,指定了⼼跳检测HTTP的版本，XXX为检测时请求
#服务器的request中的域名是什么，这个在应⽤的检测URL对应的功能有对域名依赖的话需要设置option httpchk GET /member/login.jhtml HTTP/1.1\r\nHost:
#服务器定义，cookie 1表⽰serverid为1，check inter 1500 是检测⼼跳频率
#rise 3是3次正确认为服务器可⽤，fall 3是3次失败认为服务器不可⽤，weight代表权重
server mms1 10.1.5.134:80 cookie 1 check inter 1500 rise 3 fall 3 weight 1
server mms2 10.1.6.118:80 cookie 2 check inter 1500 rise 3 fall 3 weight 2
backend denali_server
mode http
#负载均衡的⽅式，source根据客户端IP进⾏哈希的⽅式
balance source
#但设置了backup的时候，默认第⼀个backup会优先，设置option allbackups后
#所有备份服务器权重⼀样
option allbackups
#⼼跳检测URL设置
option httpchk GET /mytaobao/home/my_taobao.jhtml HTTP/1.1\r\nHost:
#可以根据机器的性能不同，不使⽤默认的连接数配置⽽使⽤⾃⼰的特殊的连接数配置
#如minconn 10 maxconn 20
server denlai1 10.1.5.114:80 minconn 4 maxconn 12 check inter 1500 rise 3 fall 3
server denlai2 10.1.6.104:80 minconn 10 maxconn 20 check inter 1500 rise 3 fall 3
#备份机器配置，正常情况下备机不会使⽤，当主机的全部服务器都down的时候备备机会启⽤server dnali-back1 10.1.7.114:80 check backup inter 1500 rise 3 fall 3
server dnali-back2 10.1.7.114:80 check backup inter 1500 rise 3 fall 3
backend tm_server
mode http
#负载均衡的⽅式，leastconn根据服务器当前的请求数，取当前请求数最少的服务器balance leastconn
option httpchk GET /trade/itemlist/prepayCard.htm HTTP/1.1\r\nHost:trade.gemini.taobao.ne server tm1 10.1.5.115:80 check inter 1500 rise 3 fall 3
server tm2 10.1.6.105:80 check inter 1500 rise 3 fall 3
######reqisetbe⾃定义关键字匹配backend部分#######################
backend dynamic
mode http
balance source
option httpchk GET /welcome.html HTTP/1.1\r\nHost:
server denlai1 10.3.5.114:80 check inter 1500 rise 3 fall 3
server denlai2 10.4.6.104:80 check inter 1500 rise 3 fall 3
backend stats
mode http
balance source
option httpchk GET /welcome.html HTTP/1.1\r\n Host:
server denlai1 10.5.5.114:80 check inter 1500 rise 3 fall 3
server denlai2 10.6.6.104:80 check inter 1500 rise 3 fall 3。