共计 3072 个字符,预计需要花费 8 分钟才能阅读完成。
最近公司内部用的阿里云SLB实例感觉不够用,主要因为https实例在一个slb实例内只能创建10个,http实例好像是50个,目前这边主要都是https,随着项目的增多,slb实例费用就上去了,所以只好自建了。另一方面一些内网调用就不用创建内网SLB实例(内网实例也需要收费的-.-)
upstream
Syntax: upstream name { ... }
Default: —
Context: http
定义一个上游服务器组,样例:
upstream backend {
server backend1.example.com weight=5;
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
server backup1.example.com backup;
}
upstream内使用server指令配置每个真实后端服务器
Syntax: server address [parameters];
Default: —
Context: upstream
upstream块内的server指令中几个重要的参数
weight
=number
:设置负载权重,默认值是1,nginx默认的负载算法是wrrmax_conns
=number
:限制代理到上游服务器之间的连接数。默认值为0,即不限制max_fails
=number
:定义代理与上游服务器通信最大错误尝试次数。默认值为1,为0则禁用尝试计数fail_timeout
=time
:心跳检测间隔,代理尝试与上游服务器通信的时间,超过设定值判断为错误max_fails
则计数+1。默认值为10sbackup
:定义为备用服务器,当其他上游服务器不可用时才会使用。注意该指令不能和hash/ip_hash/random算法一起使用down
:下线上游服务器,即代理不分配流量至该服务器resolve
:如果server指令接的是域名,则可以配置该指令来实现动态切换上游服务器,需要提前配置reslover指令slow_start
=time
:设置慢启动时间
upstream块内的其他指令
- keepalive:代理与后端服务器的长链接数,减少连接创建与销毁的代销
- keepalive_requests:每个长链接最大处理请求数,超过阈值后closed该长链接,另创建新的链接
- keepalive_time:每个活动中的长链接的存活时间,超过阈值后closed该长链接,达到此时间后,将在后续请求处理后关闭连接
- keepalive_timeout:每个长链接的超时时间,在此期间与上游服务器的空闲保持连接将保持打开状态
负载均衡样例
简单样例
upstream backend {
# 30s内检查心跳发送两次包,未回复就代表该机器宕机,请求分发权重比为1:2
server 192.168.44.131:8080 weight=100 max_fails=2 fail_timeout=30s;
server 192.168.44.131:8090 weight=200 max_fails=2 fail_timeout=30s;
# 长连接数
keepalive 32;
# 每个长连接提供的最大请求数
keepalived_requests 100;
# 每个长连接没有新的请求时,保持的最长时间
keepalive_timeout 60s;
}
server {
######## 略
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 请求交给名为backend的upstream上
proxy_pass http://nginx_boot;
}
}
websocket上游服务器样例
upstream qa_backend {
hash $remote_addr consistent;
server 192.168.44.178:8080;
server 192.168.44.179:8080;
}
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
####### 略
location / {
proxy_pass http://qa_backend;
proxy_connect_timeout 5s;
proxy_read_timeout 60s;
proxy_send_timeout 30s;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "$connection_upgrade";
}
}
nginx负载均衡算法
轮询
每个请求按时间顺序逐一分配到上游服务器
upstream qa_backend {
server 192.168.44.178:8080;
server 192.168.44.179:8080;
}
加权轮询
weight 的值越大,分配到的访问概率越高
upstream qa_backend {
server 192.168.44.178:8080 weight 10;
server 192.168.44.179:8080 weight 20;
}
ip_hash
每个请求按访问 IP 的哈希结果分配,使来自同一个 IP 的访客固定访问一台后端服务器,并且可以有效解决动态网页存在的 session 共享问题
upstream qa_backend {
ip_hash
server 192.168.44.178:8080;
server 192.168.44.179:8080;
}
fair
需要配第三方插件模块 upstream_fair 模块,对比 weight、ip_hash 更加智能的负载均衡算法,fair 算法可以根据页面大小和加载时间长短智能地进行负载均衡,响应时间短的优先分配
upstream qa_backend {
server 192.168.44.178:8080 weight 10;
server 192.168.44.179:8080 weight 20;
fair;
}
url_hash
需要安装nginx的hash软件包,按访问 url 的 hash 结果来分配请求,使每个 url 定向到同一个后端服务器,可以进一步提高后端缓存服务器的效率
upstream qa_backend {
server 192.168.44.178:8080;
server 192.168.44.179:8080;
hash $request_uri;
hash_method crc32;
}
upstream中可用的变量
- $upstream_addr
- $upstream_bytes_received
- $upstream_bytes_sent
- $upstream_cache_status
- $upstream_connect_time
- $upstream_cookie_name
- $upstream_header_time
- $upstream_http_name
- $upstream_queue_time
- $upstream_response_length
- $upstream_response_time
- $upstream_status
官方文档:https://nginx.org/en/docs/http/ngx_http_upstream_module.html#upstream
正文完