• upstream

nginx upstream语法配置

haproxy 轮询机制是怎么实现的 轮询策略_haproxy 轮询机制是怎么实现的

upstream 后面跟服务名

其中包含了,域名,端口 以及权重,可以看到他既支持http协议也支持socket协议的类型,backup意味着该域名是备用的地址

后端服务器调度参数

haproxy 轮询机制是怎么实现的 轮询策略_haproxy 轮询机制是怎么实现的_02

backup不参与服务,当其他节点无法服务了,他就参与服务

max_fails 代理服务器向后端请求,一旦发现请求状态失败,会去再度请求。超过max_fails规定的次数,随即宣告失败。

接下来就“休息一会儿”,通常为10s 可以通过fail_timeout设置更长的时间

max_conns 由于nginx向upstram(服务器池)采用轮询的方式,分发请求,有的时候我们会遇到连接池中的服务器硬件性能高低不一,有的是4核,有的是24核,配置低的服务器可能根本接收不了分摊给他的请求数目。这个时候就用到了max_conns配置

haproxy 轮询机制是怎么实现的 轮询策略_运维_03

上图配置解读:8001 不提供服务;8002备用服务器;8003失败检查只执行1次,超时时间10s,结果只有8003对应的server3可以访问

在过滤规则中停掉8003

haproxy 轮询机制是怎么实现的 轮询策略_服务器_04

这时作为backup的server2可以返回。

  • nginx的轮询机制(基于请求的方式)

nginx的轮询默认采用逐一轮询的方式,例如测试用例中从8001轮询到8003

加权轮询的调度算法:如果来7个请求,5个将会落到8002上面

haproxy 轮询机制是怎么实现的 轮询策略_运维_05

重新加载配置

haproxy 轮询机制是怎么实现的 轮询策略_haproxy 轮询机制是怎么实现的_06

然而这一方法带来的问题是:如果很多操作或访问是基于cookie或者session的,轮询会打到不同的服务器上去,session和cookie也就无从保持,导致了掉线

  • ip_hash

缓存带来的问题,假如server1 server2各缓存了一部分信息,轮询可能每次跳到不同的服务器,导致每次加载的缓存内容都不一致。

根据客户访问ip的哈希值绑定在一个后端服务器上,同一ip固定访问同一服务器,缺陷:由于是代理,无法获取真正的$remote_addr,于是改进版本的nginx有了

  • url_hash(1.7.2以后版本推出)

haproxy 轮询机制是怎么实现的 轮询策略_服务器_07

关键命令: hash $request_uri 变量指代的就是

haproxy 轮询机制是怎么实现的 轮询策略_nginx_08

测试结果,无论如何都会固定展示绑定的那台服务器的内容

如果针对url中的某一个值进行hash也是可以