Nginx

1、Nginx概述

Nginx ("engine x")是一个高性能的 HTTP 和反向代理服务器；

特点： 

• 占用内存小
• 并发能力强

（Nginx采用C进行编写，能够支持高达 50,000 个并发连接数的响应，Nginx选择了 epoll and kqueue作为开发模型。）

        Nginx可以作为静态页面的 web 服务器，同时还支持 CGI 协议的动态语言，比如 pe rl 、 php
等。但是不支持 java 。 Java 程序只能通过与 tomcat 配合完成。

2、正向代理和反向代理

正向代理

        一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。
    作用：
        （1）访问原来无法访问的资源，如google
        （2） 可以做缓存，加速访问资源
        （3）对客户端访问授权，上网进行认证
        （4）代理可以记录用户访问记录（上网行为管理），对外隐藏用户信息

反向代理

        反向代理服务器位于用户与目标服务器之间，但是对于用户而言，反向代理服务器就相当于目标服务器，即用户直接访问反向代理服务器就可以获得目标服务器的资源。同时，用户不需要知道目标服务器的地址，也无须在用户端作任何设定。反向代理服务器通常可用来作为Web加速，即使用反向代理作为Web服务器的前置机来降低网络和服务器的负载，提高访问效率。
    作用：
        （1）保证内网的安全，阻止web攻击，大型网站，通常将反向代理作为公网访问地址，Web服务器是内网
        （2）负载均衡，通过反向代理服务器来优化网站的负载

正向代理中，proxy和client同属一个LAN，对server透明；
反向代理中，proxy和server同属一个LAN，对client透明。
正向代理即是客户端代理, 代理客户端, 服务端不知道实际发起请求的客户端；
反向代理即是服务端代理, 代理服务端, 客户端不知道实际提供服务的服务端。

3、负载均衡

        负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

动静分离

动静分离是指在web服务器架构中，将静态页面与动态页面或者静态内容接口和动态内容接口分开不同系统访问的架构设计方法，进而提升整个服务访问性能和可维护性。

在Nginx中：

通过 location 指定不同的后缀名实现不同的请求转发。
通过 expires 参数设置，可以使浏览器缓存过期时间，减少与服务器之前的请求和流量。

分类（了解一下即可）：

1、软/硬件负载均衡

        软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡；

        硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备，这种设备通常称之为负载均衡器，由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。

2、本地/全局负载均衡

        本地负载均衡针对本地范围的服务器群做负载均衡，全局负载均衡针对不同地理位置、不同网络结构的服务器群做负载均衡。

部署方式：

1、路由模式（推荐）

2、桥接模式

3、服务直接返回模式

4、负载均衡算法

• 轮询均衡（多台服务器依次响应请求）
• 权重轮询均衡（多台服务器按照权重比例依次响应请求）
• 随机均衡
• 权重随机均衡
• 响应速度均衡（基于ping值）
• 最少连接数均衡（基于每台服务器正在处理的连接数量）
• 处理能力均衡（基于服务的性能）
• DNS响应均衡（域名解析快的服务器先响应请求）
• 散列算法均衡（通过一致性散列算法和虚拟节点技术确保相同参数的请求总是发送到同一台服务器）
• IP地址散列（确保同一客户端请求统一转发给相同的服务器，保证会话，保证TCP长连接）
• URL散列（将相同URL的请求转发给同一台服务器）

5、均衡技术

1、基于DNS的负载均衡（所以这种代理方式是通过DNS服务中的随机名字解析域名和IP来实现负载均衡。）

2、反向代理负载均衡（如Apache/Nginx+JK2+Tomcat这种组合）

3、基于NAT（Network Address Translation）的负载均衡技术（如Linux VirtualServer，简称LVS）：该技术通过一个地址转换网关将每个外部连接均匀转换为不同的内部服务器地址，因此外部网络中的计算机就各自与自己转换得到的地址上的服务器进行通信，从而达到负载均衡的目的。

6、配置文件nginx.conf

1、全局块

        从配置文件开始到 events 块之前的内容，主要会设置一些影响nginx 服务器整体运行的配置指令，主要包括配置运行 Nginx 服务器的用户（组）、允许生成的 worker process 数，进程 PID 存放路径、日志存放路径和类型以及配置文件的引入等。

worker_process=1，这是 Nginx 服务器并发处理服务的关键配置，worker_processes 值越大，可以支持的并发处理量也越多，但是会受到硬件、软件等设备的制约 

2、events块

         events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接，常用的设置包括是否开启对多 work process 下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 word process 可以同时支持的最大连接数等。

enents{

        worker_connections 1024;

};

表示每个 work process 支持的最大连接数为 1024. 这部分的配置对 Nginx 的性能影响较大，在实际中应该灵活配置。

3、http块

这算是 Nginx 服务器配置中最频繁的部分，代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里。 需要注意的是：http 块也可以包括 http全局块、server块。

① http全局块（http全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。）

② server 块

        这块和虚拟主机有密切关系，虚拟主机从用户角度看，和一台独立的硬件主机是完全一样的，该技术的产生是为了节省互联网服务器硬件成本。 每个http块可以包括多个server块，而每个 server 块就相当于一个虚拟主机。 而每个 server 块也分为全局 server 块，以及可以同时包含多个 location 块。

1、全局 server 块

        最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或IP配置。

2、location 块

        一个 server 块可以配置多个 location 块。

        这块的主要作用是基于 Nginx 服务器接收到的请求字符串（例如 server_name/uri-string），对虚拟主机名称（也可以是IP别名）之外的字符串（例如 前面的 /uri-string）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有许多第三方模块的配置也在这里进行。

7、Nginx 配置反向代理

实例一：使用Nginx实现反向代理，例如访问www.yy.com跳转127.0.0.1:8080

1、启动一个Tomcat服务器127.0.0.1:8080；

2、修改本地 host 文件，将 www.yy.com 映射到127.0.0.1（实际服务器中无需配置）

3、在 nginx.conf 配置文件中添加：

server{
    listen 80;
    server_name www.yy.com;
    location / {
        proxy_pass http://127.0.0.1:8080;
        index index.html index.htm index.jsp
    }
}

实例二：实现效果：使用Nginx实现反向代理，根据访问的路径跳转到不同端口的服务中

Nginx监听端口为9001：
        访问 http://127.0.0.1:9001/x/ 直接跳转到127.0.0.1:8081
        访问 http://127.0.0.1:9001/y/ 直接跳转到127.0.0.1:8082

第一步，准备两个tomcat，一个8001端口，一个8002端口，并准备好页面；

第二步，修改 nginx 的配置文件在http块中添加 server{}；

server{
    listen 9001;
    server_name localhost;
    location ~ /x/ {
        proxy_pass http://localhost:8001;
    }
    location ~ /y/ {
        proxyr_pass http://localhost:8002;
    }
}

location 该指令用于匹配URL：

location [= | ~ | ~* | ^~] uri {

}

1、= ：用于不含正则表达式的 uri 前，要求请求字符串与 uri 严格匹配，如果匹配成功，就停止继续向下搜索并立即处理该请求。

2、~：用于表示 uri 包含正则表达式，并且区分大小写。

3、~*：用于表示 uri 包含正则表达式，并且不区分大小写。

4、^~：用于不含正则表达式的 uri 前，要求 Nginx 服务器找到标识 uri 和请求字符串匹配度最高的 location 后，立即使用此 location 处理请求，而不再使用 location 块中的正则 uri 和请求字符串做匹配。

注意：如果 uri 包含正则表达式，则必须要有 ~ 或者 ~* 标识。

8、Nginx 配置负载均衡

1、启动两台Tomcat

2、在nginx.conf中配置：

http{
    upstream myserver{
        ip_hash;
        server 115.28.52.63:8081 weight=1;
        server 115.28.52.63:8082 weight=1;
    }
    server{
        location / {
            proxy_pass http://myserver;
            proxy_connect_timeout 10;
        }
    }
}

在 linux 下有 Nginx 、 LVS 、 Haproxy 等等服务可以提供负载均衡服
务，而且 Nginx 提供了几种分配方式（策略）：

1、轮询（默认）

2、权重（weight）

upstream server_pool{

    server 192.168.5.21 weight=10;

    server 192.168.5.22 weight=10;

}

3、ip_hash（解决会话一致性问题）

upstream server_pool{
    ip_hash;
    server 192.168.5.21:80; 
    server 192.168.5.22:80; 
}

4、fair（第三方）

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

upstream server_pool{ 
    server 192.168.5.21:80; 
    server 192.168.5.22:80; 
    fair; 
}

9、Nginx 配置动静分离

1、一种是纯粹把静态文件独立成单独的域名，放在独立的服务器上，也是目前主流推崇的方案；

2、另外一种方法就是动态跟静态文件混合在一起发布，通过 nginx 来分开。

1.准备项目资源

2.修改nginx.conf配置文件：

server{
    listen 80;
    server_name xxx.xxx.xxx.xxx;#服务器IP地址
    location /www/ {#动态请求
        root /data/;
        index index.html index.htm;
    }
    location /image/ {#静态资源
        root /data/;
        autoindex on;#目的是为了在访问 /image 时，能够显示目录里面的内容
    }
}

 10、Nginx 原理与优化参数配置

Nginx工作原理（Master+Worker）

1、Nginx 采用的是多进程（单线程）&多路IO复用模型。使用I/O 多路复用技术的 Nginx成了”并发事件驱动“的服务器。

- Nginx 在启动后，会有开启一个master 进程和多个相互独立的 worker 进程；

- 客户端发送一个请求首先要经过 master，管理员收到请求后会将请求通知给 worker，多个 worker 以争抢的机制来抢夺任务，得到任务的 worker 会将请求经由 tomcat 等做请求转发、反向代理、访问数据库等(nginx 本身是不直接支持 java 的)；

- master进程能监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动启动新的worker进程。

注意：

        使用多进程模式，不仅能提高并发率，而且进程之间相互独立，一个 worker 进程挂了不会影响到其他 worker 进程。

设置多少个worker合适？

Nginx 和 redis 类似，都采用了 io 多路复用机制，每个 worker 都是一个独立的进程，每个进程里只有一个主线程，通过异步非阻塞的方式来处理请求，每个 worker 的线程可以把一个 cpu 的性能发挥到极致，因此，worker 数 = 服务器的 cpu 数是最为适宜的。更多的worker 数，只会导致进程相互竞争 cpu，从而带来不必要的上下文切换。

#设置worker数量
worker_processes 4
#work绑定cpu(4work绑定4cpu)
worker_cpu_affinity 0001 0010 0100 1000
#work绑定cpu(4work绑定8cpu中的4个)
worker_cpu_affinity 0000001 00000010 00000100 00001000

连接数worker_connection这个值是表示每个worker 进程所能建立连接的最大值，所以，一个 nginx 能建立的最大连接数，应该是 worker_connections * worker_processes 。当然，这里说的是最大连接数，对于HTTP 请求本地资源来说，能够支持的最大并发数量是 worker_connections * worker_processes ，如果是支持 http1.1 的浏览器每次访问要占两个连接，所以普通的静态访问最大并发数是： worker_connections * worker_processes /2 ，而如果是 HTTP作为反向代理来说，最大并发数量应该是 worker_connections *
worker_processes/4。因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。

 什么是惊群现象？

• 主进程（master 进程）首先通过 socket() 来创建一个 sock 文件描述符用来监听，然后fork生成子进程（workers 进程），子进程将继承父进程的 sockfd（socket 文件描述符），之后子进程 accept() 后将创建已连接描述符（connected descriptor）），然后通过已连接描述符来与客户端通信。
• 那么，由于所有子进程都继承了父进程的 sockfd，那么当连接进来时，所有子进程都将收到通知并“争着”与它建立连接，这就叫“惊群现象”。大量的进程被激活又挂起，只有一个进程可以accept() 到这个连接，这当然会消耗系统资源。

怎么解决惊群现象？

Nginx 提供了一个 accept_mutex 这个东西，这是一个加在accept上的一把互斥锁。即每个 worker 进程在执行 accept 之前都需要先获取锁，获取不到就放弃执行 accept()。有了这把锁之后，同一时刻，就只会有一个进程去 accpet()，这样就不会有惊群问题了。accept_mutex 是一个可控选项，我们可以显示地关掉，默认是打开的。

worker进程工作流程？

当一个 worker 进程在 accept() 这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，一个完整的请求。一个请求，完全由 worker 进程来处理，而且只能在一个 worker 进程中处理。

优点：

1、节省锁带来的开销；（每个 worker 进程都是独立的进程，不共享资源，不需要加锁。问题排查也会方便很多。）

2、独立进程，减少风险。（一个进程退出后，其它进程还在工作，服务不会中断，master 进程则很快重新启动新的 worker 进程。当然，worker 进程的也能发生意外退出。）

多进程模型每个进程/线程只能处理一路IO，那么 Nginx是如何处理多路IO呢？

如果不使用 IO 多路复用，那么在一个进程中，同时只能处理一个请求，比如执行 accept()，如果没有连接过来，那么程序会阻塞在这里，直到有一个连接过来，才能继续向下执行。

而多路复用，允许我们只在事件发生时才将控制返回给程序，而其他时候内核都挂起进程，随时待命。

核心：Nginx采用的 IO多路复用模型epoll

        epoll通过在Linux内核中申请一个简易的文件系统（文件系统一般用什么数据结构实现？B+树），其工作流程分为三部分：

• 1、调用 int epoll_create(int size)建立一个epoll对象，内核会创建一个eventpoll结构体，用于存放通过epoll_ctl()向epoll对象中添加进来的事件，这些事件都会挂载在红黑树中。
• 2、调用 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event) 在 epoll 对象中为 fd 注册事件，所有添加到epoll中的事件都会与设备驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个sockfd的回调方法，将sockfd添加到eventpoll 中的双链表。
• 3、调用 int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout) 来等待事件的发生，timeout 为 -1 时，该调用会阻塞知道有事件发生

这样，注册好事件之后，只要有 fd 上事件发生，epoll_wait() 就能检测到并返回给用户，用户就能”非阻塞“地进行 I/O 了。

　　epoll() 中内核则维护一个链表，epoll_wait 直接检查链表是不是空就知道是否有文件描述符准备好了。（epoll 与 select 相比最大的优点是不会随着 sockfd 数目增长而降低效率，使用 select() 时，内核采用轮训的方法来查看是否有fd 准备好，其中的保存 sockfd 的是类似数组的数据结构 fd_set，key 为 fd，value 为 0 或者 1。）

　　能达到这种效果，是因为在内核实现中 epoll 是根据每个 sockfd 上面的与设备驱动程序建立起来的回调函数实现的。那么，某个 sockfd 上的事件发生时，与它对应的回调函数就会被调用，来把这个 sockfd 加入链表，其他处于“空闲的”状态的则不会。在这点上，epoll 实现了一个”伪”AIO。但是如果绝大部分的 I/O 都是“活跃的”，每个 socket 使用率很高的话，epoll效率不一定比 select 高（可能是要维护队列复杂）。

可以看出，因为一个进程里只有一个线程，所以一个进程同时只能做一件事，但是可以通过不断地切换来“同时”处理多个请求。

基于 多进程+epoll， Nginx 便能实现高并发。

11、Nginx 与 多进程模式 Apache 的区别。

事件驱动适合于I/O密集型服务，多进程或线程适合于CPU密集型服务： 

1. Nginx 更主要是作为反向代理，而非Web服务器使用。其模式是事件驱动。 
2. 事件驱动服务器，最适合做的就是这种 I/O 密集型工作，如反向代理，它在客户端与WEB服务器之间起一个数据中转作用，纯粹是 I/O 操作，自身并不涉及到复杂计算。因为进程在一个地方进行计算时，那么这个进程就不能处理其他事件了。
3.  Nginx 只需要少量进程配合事件驱动，几个进程跑 libevent，不像 Apache 多进程模型那样动辄数百的进程数。 
4. Nginx 处理静态文件效果也很好，那是因为读写文件和网络通信其实都是 I/O操作，处理过程一样。

本文引用了Kim_Weir的Nginx工作原理（Master+Worker）这篇博客中的部分内容；原文链接：https://blog.csdn.net/kim_weir/article/details/80036462 。