- 基于域名的虚拟主机
- 基于端口的虚拟主机
表现形式其实大家多见过,即:
# 每个 server 就是一个虚拟主机
http {
# ...
server{
# ...
}
# ...
server{
# ...
}
}
路由
在Nginx
的配置文件中,我们经常可以看到这样的配置:
location / {
#....
}
location
在此处就起到了路由的作用,比如我们在同一个虚拟主机内定义两个不同的路由,如下:
location / {
proxy_pass https://www.baidu.com/;
}
location /api {
proxy_pass https://apinew.juejin.im/user_api/v1/user/get?aid=2608&user_id=1275089220013336¬_self=1;
}
效果如下:
因为路由的存在,为我们后续解决跨域问题
提供了一定的思路,同时配置内容和API接口等更加方便
PS:路由的功能非常强大,支持正则匹配
正向与反向代理
此处额外解释一下proxy_pass
的含义
在Nginx
中配置proxy_pass
代理转发时,如果在proxy_pass
后面的url加 /
,表示绝对根路径;
如果没有/
,表示相对路径
正向代理
- 代理客户;
- 隐藏真实的客户,为客户端收发请求,使真实客户端对服务器不可见;
- 一个局域网内的所有用户可能被一台服务器做了正向代理,由该台服务器负责 HTTP 请求;
- 意味着同服务器做通信的是正向代理服务器;
反向代理
- 代理服务器;
- 隐藏了真实的服务器,为服务器收发请求,使真实服务器对客户端不可见;
- 负载均衡服务器,将用户的请求分发到空闲的服务器上;
- 意味着用户和负载均衡服务器直接通信,即用户解析服务器域名时得到的是负载均衡服务器的 IP ;
共同点
- 都是做为服务器和客户端的中间层
- 都可以加强内网的安全性,阻止 web 攻击
- 都可以做缓存机制,提高访问速度
区别
- 正向代理其实是客户端的代理,反向代理则是服务器的代理。
- 正向代理中,服务器并不知道真正的客户端到底是谁;而在反向代理中,客户端也不知道真正的服务器是谁。
- 作用不同。正向代理主要是用来解决访问限制问题;而反向代理则是提供负载均衡、安全防护等作用。
静态服务器
静态服务器是Nginx
的强项,使用非常容易,在默认配置下本身就是指向了静态的HTML界面,如:
location / {
root html;
index index.html index.htm;
}
所以前端同学们,如果构建好了界面,可以进行相应的配置,把界面指向目标文件夹中即可,root
指的是html
文件夹
负载均衡
负载均衡功能是Nginx
另一大杀手锏,一共有5种方式,着重介绍一下。
轮询
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除,配置如下:
upstream tomcatserver {
server 192.168.0.1;
server 192.168.0.2;
}
轮询策略是默认的负载均衡策略
指定权重
即在轮询的基础之上,增加权重的概念,weight
和访问比率成正比,用于后端服务器性能不均的情况,配置如下:
upstream tomcatserver {
server 192.168.0.1 weight=1;
server 192.168.0.2 weight=10;
}
IP Hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题,配置如下:
upstream tomcatserver {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
fair
第三方提供的负载均衡策略,按后端服务器的响应时间来分配请求,响应时间短的优先分配,生产环境中有各种情况可能导致响应时间波动,需要慎用
upstream tomcatserver {
server server1;
server server2;
fair;
}
url_hash
第三方提供的负载均衡策略,按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器
upstream tomcatserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
Nginx的模块化设计
先来看看Nginx
模块架构图:
这5个模块由上到下重要性一次递减。
(1)核心模块;
核心模块是Nginx服务器正常运行必不可少的模块,如同操作系统的内核。它提供了Nginx最基本的核心服务。像进程管理、权限控制、错误日志记录等;
(2)标准HTTP模块;
标准HTTP模块支持标准的HTTP的功能,如:端口配置,网页编码设置,HTTP响应头设置等;
(3)可选HTTP模块;
可选HTTP模块主要用于扩展标准的HTTP功能,让Nginx能处理一些特殊的服务,如:解析GeoIP请求,SSL支持等;
(4)邮件服务模块;
邮件服务模块主要用于支持Nginx的邮件服务;
(5)第三方模块;
第三方模块是为了扩展Nginx服务器应用,完成开发者想要的功能,如:Lua支持,JSON支持等;
模块化设计使得Nginx方便开发和扩展,功能很强大
Nginx的请求处理流程
基于上文中的Nginx
模块化结构,我们很容易想到,在请求的处理阶段也会经历诸多的过程,Nginx
将各功能模块组织成一条链,当有请求到达的时候,请求依次经过这条链上的部分或者全部模块,进行处理,每个模块实现特定的功能。
一个 HTTP Request 的处理过程:
- 初始化 HTTP Request
- 处理请求头、处理请求体
- 如果有的话,调用与此请求(URL 或者 Location)关联的 handler
- 依次调用各 phase handler 进行处理
- 输出内容依次经过 filter 模块处理
Nginx的多进程模型
Nginx 在启动后,会有一个 master
进程和多个 worker
进程。
master
进程主要用来管理worker
进程,包括接收来自外界的信号,向各 worker 进程发送信号,监控 worker 进程的运行状态以及启动 worker 进程。
worker
进程是用来处理来自客户端的请求事件。多个 worker 进程之间是对等的,它们同等竞争来自客户端的请求,各进程互相独立,一个请求只能在一个 worker 进程中处理。worker 进程的个数是可以设置的,一般会设置与机器 CPU 核数一致,这里面的原因与事件处理模型有关
Nginx 的进程模型,可由下图来表示:
这种设计带来以下优点:
1) 利用多核系统的并发处理能力
现代操作系统已经支持多核 CPU 架构,这使得多个进程可以分别占用不同的 CPU 核心来工作。Nginx 中所有的 worker 工作进程都是完全平等的。这提高了网络性能、降低了请求的时延。
2) 负载均衡
多个 worker 工作进程通过进程间通信来实现负载均衡,即一个请求到来时更容易被分配到负载较轻的 worker 工作进程中处理。这也在一定程度上提高了网络性能、降低了请求的时延。
3) 管理进程会负责监控工作进程的状态,并负责管理其行为
管理进程不会占用多少系统资源,它只是用来启动、停止、监控或使用其他行为来控制工作进程。首先,这提高了系统的可靠性,当 worker 进程出现问题时,管理进程可以启动新的工作进程来避免系统性能的下降。其次,管理进程支持 Nginx 服务运行中的程序升级、配置项修改等操作,这种设计使得动态可扩展性、动态定制性较容易实现。
Nginx如何解决惊群现象
什么是惊群现象?
惊群效应(thundering herd)是指多进程(多线程)在同时阻塞等待同一个事件的时候(休眠状态),如果等待的这个事件发生,那么他就会唤醒等待的所有进程(或者线程),但是最终却只能有一个进程(线程)获得这个时间的“控制权”,对该事件进行处理,而其他进程(线程)获取“控制权”失败,只能重新进入休眠状态,这种现象和性能浪费就叫做惊群效应。
上文中介绍了Nginx的多进程模型,而典型的多进程模型正如文中所说,多个worker进程之间是对等的,因此当一个请求到来的时候,所有进程会同时开始竞争,最终执行的又只有一个,这样势必会造成资源的浪费。
Nginx解决该问题的思路是:不让多个进程在同一时间监听接受连接的socket,而是让每个进程轮流监听,这样当有连接过来的时候,就只有一个进程在监听那肯定就没有惊群的问题。
具体做法是:利用一把进程间锁,每个进程中都尝试获得这把锁,如果获取成功将监听socket加入wait集合中,并设置超时等待连接到来,没有获得锁的进程则将监听socket从wait集合去除。
事件驱动模型和异步非阻塞IO
承接上文,我们知道了Nginx的多进程模型后了解到,其工作进程实际上只有几个,但为什么依然能获得如此高的并发性能,当然与其采用的事件驱动模型和异步非阻塞IO的方式来处理请求有关。
Nginx服务器响应和处理Web请求的过程,是基于事件驱动模型的,它包含事件收集器、事件发送器和事件处理器等三部分基本单元,着重关注事件处理器
,而一般情况下事件处理器有这么几种办法:
- 事件发送器每传递过来一个请求,目标对象就创建一个新的进程
- 事件发送器每传递过来一个请求,目标对象就创建一个新的线程,来进行处理
- 事件发送器每传递过来一个请求,目标对象就将其放入一个待处理事件的列表,使用非阻塞I/O方式调用
第三种方式,在编写程序代码时,逻辑比前面两种都复杂。大多数网络服务器采用了第三种方式,逐渐形成了所谓的事件驱动处理库
。
事件驱动处理库
又被称为多路IO复用方法
,最常见的包括以下三种:select模型,poll模型和epoll模型。
其中Nginx就默认使用的是epoll
模型,同时也支持其他事件模型。
epoll
的帮助就在于其提供了一种机制,可以让进程同时处理多个并发请求,不用关心IO调用的具体状态。IO调用完全由事件驱动模型来管理,这样一来,当某个工作进程接收到客户端的请求以后,调用IO进行处理,如果不能立即得到结果,就去处理其他的请求;而工作进程在此期间也无需等待响应,可以去处理其他事情;当IO返回时,epoll
就会通知此工作进程;该进程得到通知后,会来继续处理未完的请求
Nginx配置的最佳实践
在生产环境或者开发环境中Nginx一般会代理多个虚拟主机,如果把所有的配置文件写在默认的nginx.conf
中,看起来会非常臃肿,因此建议将每一个虚拟文件单独放置一个文件夹,Nginx支持这样的配置,如下:
http {
# 省略中间配置
# 引用该目录下以 .conf 文件结尾的配置
include /etc/nginx/conf.d/*.conf;
}
具体文件配置如:
# Demo
upstream web_pro_testin {
server 10.42.46.70:6003 max_fails=3 fail_timeout=20s;
ip_hash;
}
server {
listen 80;
server_name web.pro.testin.cn;
location / {
proxy_pass http://web_pro_testin;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location ~ ^/(WEB-INF)/ {
deny all;
}
}
Nginx全量配置参数说明
# 运行用户
user www-data;
# 启动进程,通常设置成和cpu的数量相等
worker_processes 6;
# 全局错误日志定义类型,[debug | info | notice | warn | error | crit]
error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;
# 进程pid文件
pid /var/run/nginx.pid;
# 工作模式及连接数上限
events {
# 仅用于linux2.6以上内核,可以大大提高nginx的性能
use epoll;
# 单个后台worker process进程的最大并发链接数
worker_connections 1024;
# 客户端请求头部的缓冲区大小
### 最后
**对于很多Java工程师而言,想要提升技能,往往是自己摸索成长,不成体系的学习效果低效漫长且无助。**
**整理的这些资料希望对Java开发的朋友们有所参考以及少走弯路,本文的重点是你有没有收获与成长,其余的都不重要,希望读者们能谨记这一点。**
**再免费分享一波我的Java面试真题+视频学习详解+技能进阶书籍**
**[点击这里即可免费获取以上我收集整理的全部学习资料](https://gitee.com/vip204888/java-p7)**
# 单个后台worker process进程的最大并发链接数
worker_connections 1024;
# 客户端请求头部的缓冲区大小
### 最后
**对于很多Java工程师而言,想要提升技能,往往是自己摸索成长,不成体系的学习效果低效漫长且无助。**
**整理的这些资料希望对Java开发的朋友们有所参考以及少走弯路,本文的重点是你有没有收获与成长,其余的都不重要,希望读者们能谨记这一点。**
**再免费分享一波我的Java面试真题+视频学习详解+技能进阶书籍**
**[点击这里即可免费获取以上我收集整理的全部学习资料](https://gitee.com/vip204888/java-p7)**
![美团二面惜败,我的凉经复盘(附学习笔记+面试整理+进阶书籍)](https://img-blog.csdnimg.cn/img_convert/6ef36db3dcf746d33f217367af5f9a5a.png)