Nginx负载均衡

507次阅读
没有评论

共计 3072 个字符,预计需要花费 8 分钟才能阅读完成。

Nginx负载均衡

最近公司内部用的阿里云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默认的负载算法是wrr
  • max_conns=number:限制代理到上游服务器之间的连接数。默认值为0,即不限制
  • max_fails=number:定义代理与上游服务器通信最大错误尝试次数。默认值为1,为0则禁用尝试计数
  • fail_timeout=time:心跳检测间隔,代理尝试与上游服务器通信的时间,超过设定值判断为错误max_fails则计数+1。默认值为10s
  • backup:定义为备用服务器,当其他上游服务器不可用时才会使用。注意该指令不能和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

正文完
 
xadocker
版权声明:本站原创文章,由 xadocker 2019-10-12发表,共计3072字。
转载说明:除特殊说明外本站文章皆由CC-4.0协议发布,转载请注明出处。
评论(没有评论)