We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No description provided.
The text was updated successfully, but these errors were encountered:
1.轮询模式:这种方式是nginx.conf配置文件的默认配置方式,当客户端访问服务的时候,请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除
upstream backserver { server 192.168.0.14; server 192.168.0.15; }
2.weight权重模式:这种方式比较灵活,当后端服务器性能存在差异的时候,通过配置权重,可以让服务器的性能得到充分发挥,有效利用资源。weight和访问比率成正比,用于后端服务器性能不均的情况。权重越高,在被访问的概率越大
http{ server{ listen 80; location / { proxy_pass http://blance; } } upstream blance{ server 172.17.0.18:8080 weight=10; server 172.17.0.14:8080 weight=20; server 172.17.0.46:8080 weight=70; } }
3.ip_hash:配置很简单,在upstream中采用ip_hash指令,如果客户已经访问了某个服务器,当用户再次访问时,会将该请求通过哈希算法,自动定位到该服务器。每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。此种策略,可以实现同一个用户访问同一台服务器,会话不会丢失,但是可能会分配不均
upstream backserver{ ip_hash; server 192.168.0.14:88; server 192.168.0.15:80; }
4.fair(第三方插件):这种方式根据后端服务器的响应时间进行分配,响应快的优先分配请求
upstream backserver{ server server1; server server2; fair }
5.url hash(第三方插件):此种方式和ip_hash比较类似,根据url的hash值进行分配,将url分配到同一个后端服务器,当服务器存在缓存时比较有效
upstream backserver{ server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; }
nginx.conf中命令说明
down 表示单前的server暂时不参与负载
weight 默认为1.weight越大,负载的权重就越大。
max_fails:允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream模块定义的错误
fail_timeout:max_fails次失败后,暂停的时间。
backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻
Sorry, something went wrong.
No branches or pull requests
No description provided.
The text was updated successfully, but these errors were encountered: