nginx入门-CSDN博客

这块和虚拟主机有密切联系，从用户角度看，虚拟主机和一台硬件主机是完全一样的，该技术是为了节省服务器硬件成本。每个http块可以包含多个server块，每个server块相当于一个虚拟主机
server块可以分为全局server块和location块
1）全局server块
最常见的配置是本虚拟机监听配置或名称、ip配置
2）location块
每个server块包含多了location块，这部分主要配置nginx接收到的请求进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有很多第三方模块配置也在这里

5 反向代理

准备工作：写一个pringboot简单项目，打包发送到linux服务器上，效果如下

5.1 通过访问nginx来实现对server1服务的访问

nginx请求转发配置如下
在location块里添加如下一行配置即可
proxy_pass http://127.0.0.1:8089;

然后重新加载配置文件，浏览器输入http://192.168.249.200/server/name即可访问到服务

5.2 根据请求路径路由

如果有参数则路由到http://127.0.0.1:8090，如果没有则路由到http://127.0.0.1:8089
新建服务server2，打包上传，访问效果如下：http://192.168.249.200:8090/server/name
访问：http://192.168.249.200:8089/server/info1获得server1
访问：http://192.168.249.200:8090/server/info2获得server2
目标是根据地址转发，如果是info1则转发到8089端口，如果是info2则转发到8090端口
添加如下配置即可
location ~ /info1 {
proxy_pass http://127.0.0.1:8089;
}

location ~ /info2 {
proxy_pass http://127.0.0.1:8090;
}
效果如下：
http://192.168.249.200/server/info1

http://192.168.249.200/server/info2

5.3 location匹配规则

~ #波浪线表示执行一个正则匹配，区分大小写
~* #表示执行一个正则匹配，不区分大小写
^~ #^~表示普通字符匹配，如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录
= #进行普通字符精确匹配
@ #"@" 定义一个命名的 location，使用在内部定向时，例如 error_page, try_files

6 负载均衡

6.1 配置示例

server1和server2都有/server/name的url，这里通过访问nginx访问这个url，实现负载均衡的效果，配置如下：
在http块中配置upstream分流
upstream myserver{
server 127.0.0.1:8089;
server 127.0.0.1:8090;
}
location中配置
proxy_pass http://myserver;

然后访问http://192.168.249.200/server/name，会看到负载均衡效果

6.2 负载均衡策略

6.2.1 轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstream myserver {
server 127.0.0.1:8089;
server 127.0.0.1:8090;
}

6.2.2 指定权重

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
upstream myserver {
server 127.0.0.1:8089 weight=5;
server 127.0.0.1:8090 weight=10;
}

6.2.3 IP绑定 ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
upstream myserver {
   ip_hash;
   server 127.0.0.1:8089;
   server 127.0.0.1:8090;
}

6.2.4 least_conn

把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。
upstream myserver {
least_conn;
server 127.0.0.1:8089;
server 127.0.0.1:8090;
}

6.2.5 fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream myserver {
   fair;
   server 127.0.0.1:8089;
   server 127.0.0.1:8090;
}

6.2.6 url_hash

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。这个有第三方依赖，不做过多讲解

7 nginx工作原理

7.1 master-worker工作机制

nginx启动后有两个进程，一个master，一个worker。

master进程主要用来管理worker进程，包含

接收来自外界的信号；
向各worker进程发送信号；
监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程

worker进程
而基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。
客户端发送请求到nginx的master，master得到任务后把任务下发给worker，worker通过争抢机制获取任务后再转发给别的服务器进行处理。

7.2 master-worker好处

1 降低nginx服务器风险

由于每个worker都占用不同的进程，互相不受影响。如果一个worker进程由于异常退出后，仅仅影响该worker正在执行的请求，其他的worker不受影响仍然可以继续工作。同时master很快启动新的worker进程。

2 效率高

每个worker占用不同的进程，不需要加锁，减少加锁带来的开销

7.3 worker个数设置

nginx和redis都采用了io多路复用的机制，每个worker是一个独立的进程，每个进程里只有一个主线程，通过异步非阻塞方式来处理请求，即使成千上万个请求也不再话下。每个worker进程会把一个CPU发挥到极致，所以worker数和CPU数相等是最适宜的。少了会浪费CPU，多了会频繁上下文切换带来损耗

7.4 worker_connections配置

发送一个请求占用worker2个或4个连接数。
如果访问本地静态资源，则占用两个连接。客户端请求worker和worker把资源返回给客户端。
如果访问动态资源，则占用4个连接。如客户端通过nginx访问java服务，先发送请求给worker，然后worker发送请求给java服务，java服务把响应给nginx，nginx把响应给客户端。
每个worker支持的最大连接数是1024，则最大支持并发是512或者256