upstream模块
- 对于upstream模块而说，它默认已经被编译进Nginx中了
- 想禁用的话，通过 `–without-http_upstream_model 这样一个参数来明确的禁用
1 ）基本用法
1.1 upstream
语法： upstream name { … }
默认值：无
上下文：http
示例
upstream { ...... ...... }
1.2 server
和 upstream 段平行，用于指定我们后端的一个具体应用服务的一个具体地址
语法：server address [parameters];
- address 是ip地址+端口，后面可跟一些url
默认值：无
上下文：upstream
parameters 可选值
可选参数
含义
weight=number
权重值，默认为1
max_conns=number
上游服务器的最大并发连接数
fail_timeout=time
服务器不可用的判定时间
max_fails=number
服务器不可用的检查次数
backup
备份服务器，仅当其他服务器都不可用时
down
标记服务器长期不可用，离线维护
- weight 权重值越大，代表这台服务器的处理能力更强，被分配的请求会更多
- max_conns 定义之后，超出直接拒绝
- fail_timeout 会启动一个计数器，结合 max_fails
- max_fails 最大失败次数，结合 fail_timeout
- 定义 fail_timeout 为 10s, max_fails 为 3
- 10s 内如果出现3次没有返回结果，则判定当前服务器不可用
- backup 当所有其他服务器挂掉不可用了，才会将请求调度到 backup 服务器
- down 永远不会被调度
1.3 keepalive
语法：keepalive connections;
- 这个 connections 不宜过大
默认值：无
上下文：upstream
示例：keepalive 16;
是限制每一个worker子进程与上游服务器，建立空闲长连接的一个最大数量
可以通过keepalive这样一个参数来启用Nginx与上游服务器之间的一个长连接功能
启用长连接的情形下的话，有很多的并发请求都调度给某一台上游服务器，上游服务器处理完之后，结果都返回给Nginx了
如果开启长连接功能，这些连接可能并不会关闭, 存在这样一种情形，某一个时刻并发请求特别多，超过了五千个并发连接
上游服务器处理完之后，把这五千个请求全部返回给Nginx，但是在这时候没有任何请求了，那这五千千个连接都在这空闲着吗？
所以会很浪费的，因为你又开启了keepalive长连接功能，所以同时这五千个链接都会在这保持长连接
所以说我们的keepalive后面跟一个connection的这样一个参数，就定义了Nginx和后端的上游服务器可以开启的长连接的一个空闲长连接的最大数量
示例中：
keepalive 16;也就是说在一个时刻内，Nginx到上游服务器的空闲的长连接是16个，所谓空闲的长连接就是这个长连接TCP连接接建立着，但是上面没有请求去发送，但这就是空闲的长连接这个也是有利于我们去更好的去复用这个系统资源，避免某些极端情况的发生的
1.4 keepalive_requests
- 语法：keepalive_requests number;
- 默认值：keepalive_requests 100;
- 上下文：upstream
- 单个长连接可以处理的最多的HTTP请求个数
- 建立一个长连接之后, 不可能无限制制的允许请求的发生, 也不能无限限制的让这个长连接一直存在
- 假如说你这个长接接不不停的发送HTTP请求，最多发送100个HTTP请求之后，就要强制关闭
- 如果客户端还有请求发送过来，把这个长连接关闭掉之后，再次启动一个新的连接给你处理请求
1.5 keepalive_timeout
- 语法：keepalive_timeout time;
- 默认值：keepalive_timeout 60s
- 上下文：upstream
- 空闲长连接的最长保持时间
- 当现在系统比较空闲的时候，仍然保持了很多长连接
- 这个时候，每一个长连接最长保持多长时间，也是有一定的限制的
- 长期没有请求在这个长链接上发送的话，可以通过keepalive_timeout 后面定义这样一个时间值，比如说60秒内
- 这个长连接上60秒内没有任何请求发送的话，那这个长连接会被自动销毁
1.6 queue (商业版，开源没有)
- 语法：queue number [timeout=time]
- 默认值：无
- 上下文：upstream
- 示例：queue 100 timeout=30s;
- 这里的 100 是队列长度
- 所有上游服务器不可用时，请求会被放到队列中等待
2 ）配置示例
upstream back_end { server 127.0.0.1:8080 weight=3 max_conns=1000 fail_timeout=10s max_fails=2; keepalive 32； keepalive_requests 50； keepalive_timeout 30s; }应用程序服务器的配置示例
总配置目录：/etc/nginx/nginx.conf
include /etc/ngin/conf.d/*.conf;vim /etc/nginx/conf.d/app_server.conf 单个可用的配置
server { listen 8080; server_name localhost; location /proxy/ { root /opt/nginx/html/app; index proxy.html; } }$
mkdir /opt/nginx/html/app/proxy -p && cd /opt/nginx/html/app/proxy写一个脚本，产生随机数，模拟动态服务 $
vim create_random_number.sh#!/bin/bash # DIR=/opt/nginx/html/app/proxy FILE=proxy.html while true;do echo "Application Server,This time create number: $RANDOM" > $DIR/$FILE sleep 1 done运行脚本 $
nohup sh create_random_number.sh &多次查看，发现文件有变化 $
cat proxy.html基于这种形式来模拟动态服务多次通过 $
curl localhost:8080/proxy/可查看对应的变化
反向代理配置示例
1 ）proxy_pass 指令
- 由http_proxy模块提供(ngx_http_proxy_module)
- 默认已被编译进nginx
- 禁用须通过
--without-http_proxy_module - 语法：proxy_pass URL;
- URL 的参数原则
- URL 必须以 http(s) 开头
- URL 可以携带变量
- URL 中是否带uri, 回直接影响发往上游请求的URL
- URL 的参数原则
- 默认值：无
- 上下文：location、if、limit_except
- 示例一：proxy_pass http:/127.0.0.1:8080
- 示例二：proxy_pass http:/127.0.0.1:8090/proxy
2 ）配置示例 proxy.conf
upstream back_end { server 192.168.184.20:8080 weight=2 max_conns=1000 fail_timeout=10s max_fails=3; keepalive 32； keepalive_requests 80； keepalive_timeout 20s; } server { listen 80； server_name proxy.baidu.com; location /proxy { proxy_pass http://back_end/proxy; } }- 本机 proxy.baidu.com 配置好 hosts
- 访问：proxy.baidu.com/proxy 同样可以看到变化的效果
- 这里会寻找上游服务器中的 proxy.html，之前上游服务器的脚本仍旧还在运行
- 这里仍然会动态改变 proxy.html 的内容
3 ）proxy 常见误区
两种常见用法
- proxy_pass http://192.168.184.20:8080
- proxy_pass http://192.168.184.20:8080/
- 带 / 和 不带 / 用法区别
- A. 不带/意味着Nginx不会修改用户URL,而是直接透传给上游的应用服务器
配置示例
location /bbs/ { proxy_pass http://127.0.0.1:8080 }用户请求url: /bbs/abc/test.html
请求到达Nginx的url: /bbs/abc/test.html
请求到达上游服务器的url: /bbs/abc/test.html
- B. 带/意味着Nginx会修改用户url,修改方法：将location后的URL从用户URL中删除
配置示例
location /bbs/ { proxy_pass http://127.0.0.1:8080/ }用户请求url: /bbs/abc/test.html
请求到达Nginx的url: /bbs/abc/test.html
请求到达上游应用服务器的url: /abc/test.html
- A. 不带/意味着Nginx不会修改用户URL,而是直接透传给上游的应用服务器
- 代理到上游服务器的URL结尾是否有必要加 /
- 这个根据上述示例来选择场景应用
