Nginx的高并发得益于epoll 模型，这种模型是异步非阻塞的，而Apache使用的是select 模型

select模型：句柄有事件响应时，select 遍历所有的句柄才能获取哪些句柄有事件通知

epoll 模型：epoll 对于句柄事件的选择不是遍历，而是事件响应，句柄上有事件就马上选择出来。

（1）select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。

（2）select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。

nginx -t

//这个命令是检测配置文件是否正确。

//最好在nginx -s reload 命令之前执行-t ,x先检查配置文件

location 匹配规则及优先级

语法规则：

=

^~

~

~*

/

/url

样例解释

location = /url 等号表示精准匹配，只有完全匹配上才会生效，如找到，停止搜索

location ^~ /url ^~开头表示对URL路径进行前缀匹配，并且在正则匹配之前，若找到，停止匹配

location ~ /url 表示区分大小写的正则匹配，按照配置文件顺序匹配

location ~*表示不区分大小写的正则匹配，按照配置文件顺序匹配

location /url 不带任何修饰符，表示前缀匹配，在正则匹配之后

location / 一般匹配，任何没有匹配到其他的location的请求都会匹配到，相当于default

优先级

精确匹配 > 正则匹配 > 一般匹配

题目

location = / {
[ configuration A ]
}
location / {
[ configuration B ]
}
location /documents/ {
[ configuration C ]
}
location ^~ /images/ {
[ configuration D ]
}
location ~* .(gif|jpg|jpeg)$ {
[ configuration E ]
}
The “/” request will match configuration [], A
the “/index.html” request will match configuration [], B
the “/documents/document.html” request will match configuration [], C
the “/images/1.gif” request will match configuration [], D
and the “/documents/1.jpg” request will match configuration [].

E

静态页面管理
每个应用中通常都会有很多的静态资源，比如jpg,png,css,js等等。这些静态资源如果每次都需要从服务器请求无疑会浪费很多资源。这个时候就可以使用nginx实现动静分离。
server {
listen 80;
server_name localhost;
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
root html/static;
expires 1d;
#表示缓存在本地一天
}
}
虚拟主机

在真实的服务器环境，为了充分利用服务器资源，一台nginx服务器会同时配置N个虚拟域名主机，即多个域名对同一个80端口。

也可以用使用相同的域名配置不同的端口区分不同的虚拟主机。

Nginx提供了三种虚拟主机配置方式，

  1. 基于ip的虚拟主机，
  2. 基于端口的虚拟主机，
  3. 基于域名的虚拟主机。

最常用的是第三种，相对于 ip地址和端口号，域名更方便记忆和使用。

Java项目 portal模块 java项目模块有哪些_nginx

修改nginx.conf文件，添加两个虚拟主机，如下：

#配置虚拟主机a.test.com
server { #监听的ip和端口，配置本机ip和端口
listen 80;
#虚拟主机名称是a.test.com，请求域名a.test.com的url将由此server配置解析
server_name a.test.com;
#所有的请求都以/开始，所有的请求都可以匹配此
location location / {
#使用root指令指定虚拟主机目录即网页存放目录
root a_html;
#指定欢迎页面，按从左到右顺序查找
index index.html index.htm;
}
}
#配置虚拟主机b.test.com
server {
listen 80;
server_name b.test.com;
location / {
root b_html;
index index.html index.htm;
}
}

######反向代理

Nginx服务器的反向代理服务是其最常用的重要功能，由反向代理服务可以衍生出很多与此相关的nginx服务器重要功能。

我们工作中最常用的也是配置反向代理。

反向代理，其实客户端对代理是无感知的，因为客户端不需要任何配置就可以访问，我们只需要将请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据后，在返回给客户端，此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了真实服务器IP地址。

Java项目 portal模块 java项目模块有哪些_Java项目 portal模块_02

server {
listen 80;
server_name localhost;
location / {
#代理的地址
proxy_pass http://server2:8888;
}
}
负载均衡

当我们的业务规模越来越大的时候，访问量持续上升，此时一台服务器肯定是扛不住的。必需搭建集群，使用nginx的反向代理，由nginx将请求分发到每台机器，并进行负载均衡。

nginx 的 upstream目前支持 4 种方式的分配

  1. 轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

  1. weight

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

  1. ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

  1. fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

  1. url_hash（第三方）

#配置上游服务器

upstream myservers {
server server2:8888 weight=10;
server server3:9999 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://myservers;
}
}

pstream 每个设备的状态:

1.down 表示单前的server暂时不参与负载

  1. weight 默认为1 。weight越大，负载的权重就越大。

3.max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误

4.fail_timeout: max_fails 次失败后，暂停的时间。

5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

共享会话
  1. Ip_hash

使用ip_hash这种方式的话，虽然可以达到共享会话的目的，但是假如我们3台tomcat同时在工作，访问nginx，由nginx进行负载在其中一台tomcat，假如此时这台tomcat出现故障无法访问，这时会话就不共享了。

  1. 基于cookie

我们也可以把用户的各种信息保存在cookie中，用户每次请求都携带cookie，接收到请求后就可以拿到cookie中的数据。但显而易见，这种方式十分危险。

基于db(各种关系型数据库和非关系型数据库)

当然我们也可以将数据直接保存在数据库中，但如果访问量大，会频繁访问数据库，对数据库造成很大的压力。

  1. 基于redis+cookie共享session

最好的方式就是将用户信息放到redis中进行存储，由于是基于内存，因此效率非常高。 此时cookie中只需保存我们redis中的key，用户每次请求只要拿到cookie中的key然后再到redis中拿用户信息，不仅安全了，效率也提高了。

Java项目 portal模块 java项目模块有哪些_服务器_03

keepalive

是在TCP中一个可以检测死连接的机制。keepalive实现Nginx高可用确保一个Nginx挂掉后可以重新启动

保留几分配置

1.静态文件
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - time_local] “$request” ’'$status http_referer" ’‘“http_x_forwarded_for”’;#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
server {
listen 8888;
server_name localhost;
location ~* .(jpg|txt|rar|mp4|)$ {
root E:/NGINX/nginx-1.16.0/file;
#expires 1d; #表示缓存在本地一天
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
another virtual host using mix of IP-, name-, and port-based configuration
#server {
listen 8000;
listen somename:8080;
server_name somename alias another.alias;
location / {

root html;
index index.html index.htm;
}
#}
HTTPS server
#server {
listen 443 ssl;
server_name localhost;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location / {

root html;
index index.html index.htm;
}
#}
}
2.虚拟主机
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;