Nginx基础和原理介绍

一、nginx基本概念

1、nginx简介

nginx是一个反向代理服务器，特点是占用内存少，并发能力强，在同类的网页服务器中表现较好。

nginx专门为性能优化而开发，性能是其最重要的考量，有报告表能支持高达50000并发连接数。

2、nginx功能

【1】反向代理

正向代理：由客户端向代理指定它要访问哪个原始的服务器，然后又代理将请求转发给对应的服务器。向vpn就是正向代理，客户端访问不了外网。

反向代理：客户端指访问代理服务器，它并不知道它访问的原始服务器是谁，有代理服务器根据配置规则转发给相应的原始服务器。反向代理访问的实际是一个虚拟的ip，不是最终实际的ip地址。

【2】负载均衡

单个web应用服务器不能承受日益增长的并发请求量，因此我们需要不断的扩张web应用服务器来支持更高的并发请求量。需要均匀的将请求分配到各个应用服务器上就是负载均衡，常用的策略有轮询策略。

nginx提供的负载均衡策略有2种：内置策略和扩展策略。内置策略为轮询，加权轮询，Ip hash。扩展策略，就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他一一找出来做下实现。

Ip hash算法，对客户端请求的ip进行hash操作，然后根据hash结果将同一个客户端ip的请求分发给同一台服务器进行处理，可以解决session不共享的问题。

【3】动静分离

为了加快网站的解析速度，将动态页面和静态页面由不同的服务器来解析，加快解析速度，降低原来单个服务器的压力。将静态文件放在一个单独的web服务器上。

3、nginx配置文件介绍

【1】各部分介绍

...              #全局块events {         #events块...
}http      #http块
{...   #http全局块server        #server块{ ...       #server全局块location [PATTERN]   #location块{...}location [PATTERN] {...}}server{...}...     #http全局块
}

全局块：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。
events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。
http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。
server块：配置虚拟主机的相关参数，一个http中可以有多个server。
location块：配置请求的路由，以及各种页面的处理情况。

【2】配置实例

########### 每个指令必须有分号结束。#################
#user administrator administrators;  #配置用户或者组，默认为nobody nobody。
worker_processes 2;  #允许生成的进程数，默认为1
#pid /nginx/pid/nginx.pid;   #指定nginx进程运行文件存放地址
#制定日志路径，级别。这个设置可以放入全局块，http块，server块，级别以此为：debug|info|notice|warn|error|crit|alert|emerg
error_log log/error.log debug;  events {accept_mutex on;   #设置网路连接序列化，防止惊群现象发生，默认为onmulti_accept on;  #设置一个进程是否同时接受多个网络连接，默认为off#use epoll;      #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventportworker_connections  1024;    #最大连接数，默认为512
}http {include       mime.types;   #文件扩展名与文件类型映射表default_type  application/octet-stream; #默认文件类型，默认为text/plain#access_log off; #取消服务日志    log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格式access_log log/access.log myFormat;  #combined为日志格式的默认值sendfile on;   #允许sendfile方式传输文件，默认为off，可以在http块，server块，location块。sendfile_max_chunk 100k;  #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。keepalive_timeout 65;  #连接超时时间，默认为75s，可以在http，server，location块。upstream mysvr {   server 127.0.0.1:7878;server 192.168.10.121:3333 backup;  #热备}error_page 404 https://www.baidu.com; #错误页server {keepalive_requests 120; #单连接请求上限次数。listen       4545;   #监听端口server_name  127.0.0.1;   #监听地址       location  ~*^.+$ {       #请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。#root path;  #根目录#index vv.txt;  #设置默认页proxy_pass  http://mysvr;  #请求转向mysvr 定义的服务器列表deny 127.0.0.1;  #拒绝的ipallow 172.18.5.54; #允许的ip           } }
}

3、nginx配置反向代理

【1】简单配置

error_log log/error.log debug;
sendfile on;events {accept_mutex on;multi_accept on;worker_connections  1024;
}http {keepalive_timeout 65;upstream mysvr {   server 127.0.0.1:7878;server 192.168.10.121:3333 backup;}error_page 404 https://www.baidu.com;server {keepalive_requests 120;listen       80;server_name  127.0.0.1; location / {proxy_pass  http://mysvr; } }
}

【2】实现不同url路由到不同端口

error_log log/error.log debug;
sendfile on;events {accept_mutex on;multi_accept on;worker_connections  1024;
}http {keepalive_timeout 65;error_page 404 https://www.baidu.com;server {keepalive_requests 120;listen       80;server_name  127.0.0.1; location ~ /edu/ {proxy_pass  http://127.0.0.1:8080; } location ~ /vod/ {proxy_pass  http://127.0.0.1:8081;} }
}

【3】location匹配表达式

= 开头表示精确匹配如 A 中只匹配根目录结尾的请求，后面不能带任何字符串。

^~ 开头表示uri以某个常规字符串开头，不是正则匹配: 开头表示区分大小写的正则匹配;

~* 开头表示不区分大小写的正则匹配

/ 通用匹配, 如果没有其它匹配,任何请求都会匹配到

4、nginx配置负载均衡

upstream myServer {    server 192.168.72.49:9090 down;   server 192.168.72.49:8080 weight=2;   server 192.168.72.49:6060;   server 192.168.72.49:7070 backup;
}

1）down

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

2）Weight

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

3）max_fails

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

4）fail_timeout

max_fails 次失败后，暂停的时间。

5）Backup

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

5、nginx配置动静分离

动静分离：

所谓动静分离指的是当访问静态资源时，路由到一台静态资源服务器,当访问是非静态资源时，路由到另外一台服务器

实例

worker_processes  1;
events {worker_connections  1024;
}
http {server {listen       10000;server_name  localhost;#拦截后台请求location / {proxy_pass http://localhost:8888;proxy_set_header X-Real-IP $remote_addr;}#拦截静态资源location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|js|css)$ {root /Users/dalaoyang/Downloads/static;autoindex on;}}
}

6、nginx配置高可用集群

需要借助keepalived实现

【1】keepalived介绍

Keepalived软件起初是专为LVS负载均衡软件设计的，用来管理并监控LVS集群系统中各个服务节点的状态，后来又加入了可以实现高可用的VRRP (Virtual Router Redundancy Protocol ,虚拟路由器冗余协议）功能。因此，Keepalived除了能够管理LVS软件外，还可以作为其他服务（例如：Nginx、Haproxy、MySQL等）的高可用解决方案软件

【2】故障转移机制

Keepalived高可用服务之间的故障切换转移，是通过VRRP 来实现的。
在 Keepalived服务正常工作时，主 Master节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备Backup节点自己还活着，当主 Master节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主 Master节点的心跳了，于是调用自身的接管程序，接管主Master节点的 IP资源及服务。而当主 Master节点恢复时，备Backup节点又会释放主节点故障时自身接管的IP资源及服务，恢复到原来的备用角色。

【3】keepalived主配置

在nginx主节点机器上安装keepalived；修改keepalived配置如下

Copyvi keepalived.conf
keepalived.conf:
Copy#检测脚本
vrrp_script chk_http_port {script "/usr/local/src/check_nginx_pid.sh" #心跳执行的脚本，检测nginx是否启动interval 2                          #（检测脚本执行的间隔，单位是秒）weight 2                            #权重
}
#vrrp 实例定义部分
vrrp_instance VI_1 {state MASTER            # 指定keepalived的角色，MASTER为主，BACKUP为备interface ens33         # 当前进行vrrp通讯的网络接口卡(当前centos的网卡) 用ifconfig查看你具体的网卡virtual_router_id 66    # 虚拟路由编号，主从要一直priority 100            # 优先级，数值越大，获取处理请求的优先级越高advert_int 1            # 检查间隔，默认为1s(vrrp组播周期秒数)#授权访问authentication {auth_type PASS #设置验证类型和密码，MASTER和BACKUP必须使用相同的密码才能正常通信auth_pass 1111}track_script {chk_http_port            #（调用检测脚本）}virtual_ipaddress {192.168.16.130            # 定义虚拟ip(VIP)，可多设，每行一个}
}

【4】keepalived从节点配置

在nginx从节点上安装keepalived；修改配置如下

keepalived.conf:
Copy#检测脚本
vrrp_script chk_http_port {script "/usr/local/src/check_nginx_pid.sh" #心跳执行的脚本，检测nginx是否启动interval 2                          #（检测脚本执行的间隔）weight 2                            #权重
}
#vrrp 实例定义部分
vrrp_instance VI_1 {state BACKUP                        # 指定keepalived的角色，MASTER为主，BACKUP为备interface ens33                      # 当前进行vrrp通讯的网络接口卡(当前centos的网卡) 用ifconfig查看你具体的网卡virtual_router_id 66                # 虚拟路由编号，主从要一直priority 99                         # 优先级，数值越大，获取处理请求的优先级越高advert_int 1                        # 检查间隔，默认为1s(vrrp组播周期秒数)#授权访问authentication {auth_type PASS #设置验证类型和密码，MASTER和BACKUP必须使用相同的密码才能正常通信auth_pass 1111}track_script {chk_http_port                   #（调用检测脚本）}virtual_ipaddress {192.168.16.130                   # 定义虚拟ip(VIP)，可多设，每行一个}
}

【5】设置添加检测脚本

Copy#!/bin/bash
#检测nginx是否启动了
A=`ps -C nginx --no-header |wc -l`
if [ $A -eq 0 ];then    #如果nginx没有启动就启动nginx                        systemctl start nginx                #重启nginxif [ `ps -C nginx --no-header |wc -l` -eq 0 ];then    #nginx重启失败，则停掉keepalived服务，进行VIP转移killall keepalived                    fi
fi

脚本授权:chmod 775 check_nginx_pid.sh

说明：脚本必须通过授权，不然没权限访问啊，在这里我们两条服务器执行、VIP(virtual_ipaddress:192.168.16.130),我们在生产环境是直接通过vip来访问服务。

【6】架构

二、nginx原理

1、工作流程

（1）用户通过域名发出访问Web服务器的请求，该域名被DNS服务器解析为反向代理服务器的IP地址；

（2）反向代理服务器接受用户的请求；

（3）反向代理服务器在本地缓存中查找请求的内容，找到后直接把内容发送给用户；

（4）如果本地缓存里没有用户所请求的信息内容，反向代理服务器会代替用户向源服务器请求同样的信息内容，并把信息内容发给用户，如果信息内容是缓存的还会把它保存到缓存中。

2、master-workers机制

Nginx在启动时会以daemon形式在后台运行，采用多进程+异步非阻塞IO事件模型来处理各种连接请求。多进程模型包括一个master进程，多个worker进程，一般worker进程个数是根据服务器CPU核数来决定的。master进程负责管理Nginx本身和其他worker进程。

从上图中可以很明显地看到，4个worker进程的父进程都是master进程，表明worker进程都是从父进程fork出来的，并且父进程的ppid为1，表示其为daemon进程。

需要说明的是，在nginx多进程中，每个worker都是平等的，因此每个进程处理外部请求的机会权重都是一致的。

Master进程的作用是？

读取并验证配置文件nginx.conf；管理worker进程；

Worker进程的作用是？

每一个Worker进程都维护一个线程（避免线程切换），处理连接和请求；注意Worker进程的个数由配置文件决定，一般和CPU个数相关（有利于进程切换），配置几个就有几个Worker进程。

连接数worker_aconnection和并发数关系？

表示每个worker进程所能建立的连接的最大值，如果nginx作为反向代理，最大并发数量 = work_connections * worker_process / 4 , 客户端和服务端都要占用两个连接。

Nginx如何做到热部署？

所谓热部署，就是配置文件nginx.conf修改后，不需要stop Nginx，不需要中断请求，就能让配置文件生效！（nginx -s reload 重新加载/nginx -t检查配置/nginx -s stop）

修改配置文件nginx.conf后，重新生成新的worker进程，当然会以新的配置进行处理请求，而且新的请求必须都交给新的worker进程，至于老的worker进程，等把那些以前的请求处理完毕后，kill掉即可。

3、请求处理流程

Nginx真正处理请求业务的是Worker之下的线程。worker进程中有一个ngx_worker_process_cycle()函数，执行无限循环，不断处理收到的来自客户端的请求，并进行处理，直到整个Nginx服务被停止。

worker 进程中，ngx_worker_process_cycle()函数就是这个无限循环的处理函数。在这个函数中，一个请求的简单处理流程如下：

（1）操作系统提供的机制（例如 epoll, kqueue 等）产生相关的事件。

（2）接收和处理这些事件，如是接收到数据，则产生更高层的 request 对象。

（3）处理 request 的 header 和 body。

（4）产生响应，并发送回客户端。

（5）完成 request 的处理。

（6）重新初始化定时器及其他事件。