Nginx中ngx_http_upstream_module模块

Nginx中ngx_http_upstream_module模块
⽤于将多个服务器器定义成服务器器组，⽽⽽
由 proxy_pass ， fastcgi_pass 等指令进⾏⾏行引⽤⽤
upstream backend {
server
weight=5;
server :8080
;
server unix:/tmp/backend3;
server :8080
backup;
server :8080
backup;
}
server {
location / {
proxy_pass http://backend;
}
}
指令：
16.1 upstream
定义后端服务器器组，会引⼊⼊⼀⼀个新的上下⽂⽂
Syntax: upstream name { ... }
Default: —
Context: http
16.2 server
定义服务器器 address ，可以将地址指定为域名或IP
地址，使⽤⽤可选端⼝⼝，或者指定为 unix: 前缀后指
定的 UNIX 域套接字路路径。

如果未指定端⼝⼝，则使⽤⽤
端⼝⼝80
Syntax: server address [parameters];
Default: —
Context: upstream
参数：
weight=number # 权重，默认为1
max_conns # 连接后端报务器器最⼤⼤并发活动
连接数
max_fails=number # 连接后端服务器器最⼤⼤
失败次数，超出指定的次数时， server 将
被标记为不不可⽤⽤,默认为1
fail_timeout=time # 后端服务器器在指定超
时时间内未做出回应，也会被认为不不可⽤⽤，
默认10s
backup # 将服务器器标记为 backup ，表⽰备
份服务器器（ sorry server ），即所有服务器器
均不不可⽤⽤时才启⽤⽤
down # 将服务器器标记为 down ，表⽰不不可
⽤⽤，配合 ip_hash 使⽤⽤，实现灰度发布
16.3 ip_hash
源地址 hash 调度⽅⽅法
Syntax: ip_hash;
Default: —
Context: upstream
16.4 least_conn
最少连接调度算法，当 server 拥有不不同的权重时其
为 wlc ，当所有后端主机连接数相同时，则使
⽤⽤ wrr ，适⽤⽤于⻓长连接
Syntax: least_conn;
Default: —
Context: upstream
16.5 hash
基于指定的 key 的 hash 表来实现对请求的调度，此
处的 key 可以直接⽂⽂本、变量量或⼆⼆者组合。

将请求
分类，同⼀⼀类请求将发往同⼀⼀
个 upstreamserver ，使⽤⽤ consistent 参数，将
使⽤⽤ ketama ⼀⼀致性 hash 算法，适⽤⽤于后端
是 Cache 服务器器（如 varnish ）时使⽤⽤，提⾼⾼缓存服务器器的缓存命中率
Syntax: hash key [consistent];
Default: —
Context: upstream
16.6 keepalive
为每个worker进程保留留的空闲的⻓长连接数量量,可节约nginx端⼝⼝，并减少连接管理理的消耗
Syntax: keepalive connections;
Default: —
Context: upstream
16.7 health_check （商业版）
健康状态检测机制
Syntax: health_check [parameters];
Default: —
Context: location
参数：
interval=time # 检测的频率，默认为5秒
fails=number # 判定服务器器不不可⽤⽤的失败
检测次数；默认为1次
passes=number # 判定服务器器可⽤⽤的失败检
测次数；默认为1次
uri=uri # 做健康状态检测测试的⽬⽬标uri；
默认为/match=NAME：健康状态检测的结果
评估调⽤⽤此处指定的match配置块
16.8 match （商业版）
对 backend server 做健康状态检测时，定义其结
果判断机制
Syntax: match name { ... }
Default: —
Context: http
参数
status code[ code ...] # 期望的响应状
态码
header HEADER[operator value] # ：期
望存在响应⾸⾸部，也可对期望的响应⾸⾸部的
值基于⽐⽐较操作符和值进⾏⾏行⽐⽐较
body # 期望响应报⽂⽂的主体部分应该有的内
容。