第一部分 nginx基础回顾
（一）nginx介绍
Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点(俄文:Рамблер)开发的，第一个公开版本0.1.0发布于2004年10月4日。
其将源代码以类BSD许可证的形式发布，因它的稳定性、丰富的功能集、简单的配置文件和低系统资源的消耗而闻名。2011年6月1日，nginx 1.0.4发布。
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等。
来源：360百科。
（二）nginx到底是什么？
Nginx 是⼀个⾼性能的HTTP和反向代理web服务器，核⼼特点是占有内存少，并发能⼒强。
（三）nginx应用场景（具体可以做些什么）
1. http服务器（web服务器）
性能⾮常⾼，⾮常注重效率，能够经受⾼负载的考验。
⽀持50000个并发连接数，不仅如此，CPU和内存的占⽤也⾮常的低，10000个没有活动的连接才占⽤2.5M的内存。
2. 反向代理服务器
说到反向代理，我们不得不提一下正向代理。对比更容易让我们理解正向/反向代理。
正向代理：意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。
正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径。正向代理还可以使用缓冲特性(由mod_cache提供)减少网络使用率。
使用ProxyRequests指令即可激活正向代理。因为正向代理允许客户端通过它访问任意网站并且隐藏客户端自身，因此你必须采取安全措施以确保仅为经过授权的客户端提供服务。
（来源：360百科）
反向代理：浏览器客户端发送请求到反向代理服务器（⽐如Nginx），由反向代理服务器选择原始服务器提供服务获取结果响应，最终再返回给客户端浏览器。
3. 负载均衡服务器
负载均衡：就是当⼀个请求到来的时候（结合反向代理示意图），Nginx反向代理服务器根据请求去找到⼀个原始服务器来处理当前请求，那么这叫做反向代理。那么，如果⽬标服务器有多台（⽐如上图中的tomcat1，tomcat2，tomcat3...），找哪⼀个⽬标服务器来处理当前请求呢？这样⼀个寻找确定的过程就叫做负载均衡。
⽣活中也有很多这样的例⼦，⽐如，我们去银⾏，可以处理业务的窗⼝有多个，那么我们会被分配到哪个窗⼝呢？这样的⼀个过程就叫做负载均衡。
负载均衡就是为了解决⾼负载的问题。发起多个请求，nginx会根据设置的策略来实现负载均衡，比如轮询、设置权重的方式。
4. 动静分离
Nginx特点：
跨平台：Nginx可以在⼤多数类unix操作系统上编译运⾏，⽽且也有windows版本；
Nginx的上⼿⾮常容易，配置也⽐较简单；
⾼并发，性能好；
稳定性也特别好，宕机概率很低。
Nginx安装：
1.上传nginx安装包到linux服务器，nginx安装包(.tar⽂件)下载地址：http://nginx.org
2.安装Nginx依赖，pcre、openssl、gcc、zlib（推荐使⽤yum源⾃动安装）
yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel
3.解包Nginx软件包
tar -xvf nginx-1.17.8.tar
4.进⼊解压之后的⽬录 nginx-1.17.8
cd nginx-1.17.8
5.命令⾏执⾏
./confifigure
6.命令⾏执⾏
make
7.命令⾏执⾏ make install，完毕之后在/usr/local/下会产⽣⼀个nginx⽬录。
8.进⼊sbin⽬录中，执⾏启动nginx命令。
cd nginx/sbin
./nginx
9.然后访问服务器的80端⼝（nginx默认监听80端⼝）
nginx主要命令：
./nginx 启动nginx
./nginx -s stop 终⽌nginx（当然也可以找到nginx进程号，然后使⽤kill -9 杀掉nginx进程）
./nginx -s reload (重新加载nginx.conf配置⽂件)
第二部分 Nginx核心配置文件解读
Nginx的核心配置文件conf/nginx.conf 包含三块内容：全局块、events块、http块。
（一）全局块
从配置⽂件开始到events块之间的内容，此处的配置影响nginx服务器整体的运⾏，⽐如worker进程的数量、错误⽇志的位置等。
备注：worker进程数量，通常设置为与cpu数量相等。
（二）events块
events块主要影响nginx服务器与⽤户的⽹络连接，⽐如worker_connections 1024，标识每个workderprocess⽀持的最⼤连接数为1024。
（三）http块
http块是配置最频繁的部分，虚拟主机的配置，监听端⼝的配置，请求转发、反向代理、负载均衡等。
第三部分 Nginx应用场景之反向代理
需求：两种方式实现反向代理。
需求一：实现步骤。
1 部署tomcat，保持默认监听8080端⼝。
2 修改nginx配置，并重新加载。
2.1 修改nginx配置。
2.2 重新加载nginx配置
./nginx -s reload
3 测试，访问http://111.229.248.243:9003,返回tomcat的⻚⾯。
需求二：实现步骤。
1、 再部署⼀台tomcat，保持默认监听8081端⼝。
2、 修改nginx配置，并重新加载。
3、 这⾥主要就是多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的负载均衡。
Nginx负载均衡策略
1.轮询
（默认策略，每个请求按时间顺序逐⼀分配到不同的服务器，如果某⼀个服务器下线，能⾃动剔除）。
2.weight 权重
weight代表权重，默认每⼀个负载的服务器都为1，权重越⾼那么被分配的请求越多（⽤于服务器性能不均衡的场景）。
3. ip_hash
每个请求按照ip的hash结果分配，每⼀个客户端的请求会固定分配到同⼀个⽬标服务器处理，可以解决session问题。
4. fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream backserver {
server 111.229.248.243:8080;
server 111.229.248.243:8081;
fair;
}
5. url_hash（第三方） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
在需要使用负载均衡的server中增加
proxy_pass http://backserver/;
upstream backserver{
ip_hash;
server 127.0.0.1:9090 down; (down 表示当前的server暂时不参与负载)
server 127.0.0.1:8080 weight=2; (weight 默认为1.weight越大，负载的权重就越大)
server 127.0.0.1:6060; (不写，weight 默认为1）
server 127.0.0.1:7070 backup; (其它所有的非backup机器down或者忙的时候，请求backup机器)
}
max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误 fail_timeout:max_fails次失败后，暂停的时间。
针对负载均衡失败的场景解决方案：
方案一：使用nginx失效剔除模块。可以参考这一篇博客：https://blog.51cto.com/icenycmh/2091910
方案二：搭建一个nginx管理平台，可以动态修改nginx的配置文件并重启nginx。通过运行平台发现服务宕机，自动将upstream里面的内容去掉，然后重启。支持手动和自动修改发布。（大厂用的多）
方案三：使用nginx的收费版本，里面会提供一个管理界面进行管理。
第五部分 Nginx应用场景之动静分离
动静分离就是讲动态资源和静态资源的请求处理分配到不同的服务器上，⽐较经典的组合就是Nginx+Tomcat架构（Nginx处理静态资源请求，Tomcat处理动态资源请求），那么其实之前的讲解中，Nginx反向代理⽬标服务器Tomcat，我们能看到⽬标服务器ROOT项⽬的index.jsp，这本身就是Tomcat在处理动态资源请求了。
所以，我们只需要配置静态资源访问即可。
Nginx静态资源配置：
第六部分 Nginx底层进程机制剖析
Nginx启动后，以daemon（守护线程）多进程⽅式在后台运⾏，包括⼀个Master进程和多个Worker进程，Master进程是领导，是⽼⼤，Worker进程是⼲活的⼩弟。
master进程：
主要是管理worker进程，⽐如：
1）接收外界信号向各worker进程发送信号(./nginx -s reload)
2）监控worker进程的运⾏状态，当worker进程异常退出后Master进程会⾃动重新启动新的worker进程等
worker进程：
worker进程具体处理⽹络请求。多个worker进程之间是对等的，他们同等竞争来⾃客户端的请求，各进程互相之间是独⽴的。⼀个请求，只可能在⼀个worker进程中处理，⼀个worker进程，不可能处理其它进程的请求。worker进程的个数是可以设置的，⼀般设置与机器cpu核数⼀致。
以 ./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多进程模型好处：
1）每个worker进程都是独⽴的，不需要加锁，节省开销。
2）每个worker进程都是独⽴的，互不影响，⼀个异常结束，其他的照样能提供服务。
3）多进程模型为reload热部署机制提供了⽀撑。
