nginx - nginx应用 - 《Tomcat、Nginx 学习笔记》

反向代理
- 目标服务器有一个
- 目标服务器有两个
Nginx应⽤场景之负载均衡
- Nginx负载均衡策略
Nginx应⽤场景之动静分离
Nginx底层进程机制剖析

反向代理

目标服务器有一个

部署tomcat，保持默认监听8080端⼝
修改nginx配置，并重新加载

修改nginx配置

     location / {
          #root   html;
          #index  index.html index.htm;
          proxy_pass http://127.0.0.1:8080;
      }

重新加载nginx配置
./nginx -s reload

测试，访问http://localhost:8080,返回tomcat的⻚⾯

目标服务器有两个

需求⼆完成
再部署⼀台tomcat，保持默认监听8081端⼝
修改nginx配置，并重新加载
```
      location /abc{
      proxy_pass http://127.0.0.1:8080/;
}
      location /def{
      proxy_pass http://127.0.0.1:8081/;
}
```
这⾥主要就是多location的使⽤，这⾥的nginx中server/location就好⽐tomcat中的
Host/Context
location 语法如下：
```
location [=|~|~*|^~] /uri/ { … }
```
在nginx配置⽂件中，location主要有这⼏种形式：
1）正则匹配 location ~ /lagou { }
2）不区分⼤⼩写的正则匹配 location ~* /lagou { }
3）匹配路径的前缀 location ^~ /lagou { }
4）精确匹配 location = /lagou { }
5）普通路径前缀匹配 location /lagou { }
优先级
4 > 3 > 2 > 1 > 5
Nginx应⽤场景之负载均衡

Nginx负载均衡策略

轮询
默认策略，每个请求按时间顺序逐⼀分配到不同的服务器，如果某⼀个服务器下线，能⾃动剔除

upstream lagouServer{
server 127.0.0.1:8082;
server 127.0.0.1:8080;
}
location /abc {
proxy_pass http://lagouServer/;
}

weight
weight代表权重，默认每⼀个负载的服务器都为1，权重越⾼那么被分配的请求越多（⽤于服务器
性能不均衡的场景）

upstream lagouServer{
server 127.0.0.1:8080 weight=1;
server 127.0.0.1:8082 weight=2; 
}

ip_hash
每个请求按照ip的hash结果分配，每⼀个客户端的请求会固定分配到同⼀个⽬标服务器处理，可
以解决session问题

upstream lagouServer{
ip_hash;
server 127.0.0.1:8080;
server 127.0.0.1:8082;
}

Nginx应⽤场景之动静分离

动静分离就是讲动态资源和静态资源的请求处理分配到不同的服务器上，⽐较经典的组合就是
Nginx+Tomcat架构（Nginx处理静态资源请求，Tomcat处理动态资源请求），那么其实之前的讲解
中，Nginx反向代理⽬标服务器Tomcat，我们能看到⽬标服务器ROOT项⽬的index.jsp，这本身就是
Tomcat在处理动态资源请求了。
所以，我们只需要配置静态资源访问即可。

Nginx配置

Nginx底层进程机制剖析

Nginx启动后，以daemon多进程⽅式在后台运⾏，包括⼀个Master进程和多个Worker进程，Master
进程是领导，是⽼⼤，Worker进程是⼲活的⼩弟。

master进程

主要是管理worker进程，⽐如：
接收外界信号向各worker进程发送信号(./nginx -s reload)
监控worker进程的运⾏状态，当worker进程异常退出后Master进程会⾃动重新启动新的

worker进程等

worker进程worker进程具体处理⽹络请求。多个worker进程之间是对等的，他们同等竞争来⾃客户端的请
求，各进程互相之间是独⽴的。⼀个请求，只可能在⼀个worker进程中处理，⼀个worker进程，
不可能处理其它进程的请求。worker进程的个数是可以设置的，⼀般设置与机器cpu核数⼀致。

Nginx进程模型示意图

以 ./nginx -s reload 来说明nginx信号处理这部分
1）master进程对配置⽂件进⾏语法检查
2）尝试配置（⽐如修改了监听端⼝，那就尝试分配新的监听端⼝）
3）尝试成功则使⽤新的配置，新建worker进程
4）新建成功，给旧的worker进程发送关闭消息
5）旧的worker进程收到信号会继续服务，直到把当前进程接收到的请求处理完毕后关闭
所以reload之后worker进程pid是发⽣了变化的

worker进程处理请求部分的说明

例如，我们监听9003端⼝，⼀个请求到来时，如果有多个worker进程，那么每个worker进程都有可能处理这个链接。
master进程创建之后，会建⽴好需要监听的的socket，然后从master进程再fork出多个worker进程。所以，所worker进程的监听描述符listenfd在新连接到来时都变得可读。
nginx使⽤互斥锁来保证只有⼀个workder进程能够处理请求，拿到互斥锁的那个进程注册listenfd读事件，在读事件⾥调⽤accept接受该连接，然后解析、处理、返回客户端

nginx多进程模型好处

每个worker进程都是独⽴的，不需要加锁，节省开销
每个worker进程都是独⽴的，互不影响，⼀个异常结束，其他的照样能提供服务
多进程模型为reload热部署机制提供了⽀撑

nginx应用