Nginx从入门到应用详解
Posted 耳冉鹅
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Nginx从入门到应用详解相关的知识,希望对你有一定的参考价值。
一、概述
nginx (“engine x”) 是一个高性能的 HTTP 和反向代理服务器,特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好,中国大陆使用nginx 网站用户有:百度、京东、新浪、网易、腾讯、淘宝等
Nginx 可以作为静态页面的 web 服务器,同时还支持 CGI 协议的动态语言,比如 perl、php 等。但是不支持 java。Java 程序只能通过与 tomcat 配合完成。Nginx 专为性能优化而开发, 性能是其最重要的考量,实现上非常注重效率,能经受高负载的考验,有报告表明能支持高 达 50,000 个并发连接数。
Nginx可以做到热部署,同时因为占用内存少的原因可以达到7*24小时不间断运行。
(常见关键概念:正向代理、反向代理、负载均衡、动静分离)
1、正向代理
如果把局域网外的 Internet 想象成一个巨大的资源库,则局域网中的客户端要访 问 Internet,则需要通过代理服务器来访问,这种代理服务就称为正向代理。
2、反向代理
反向代理,其实客户端对代理是无感知的,因为客户端不需要任何配置就可以访问,我们只 需要将请求发送到反向代理服务器,由反向代理服务器去选择目标服务器获取数据后,在返 回给客户端,此时反向代理服务器和目标服务器对外就是一个服务器,暴露的是代理服务器 地址,隐藏了真实服务器 IP 地址。
3、负载均衡
客户端发送多个请求到服务器,服务器处理请求,有一些可能要与数据库进行交互,服务器处理完毕后,再将结果返回给客户端。
这种架构模式对于早期的系统相对单一,并发请求相对较少的情况下是比较适合的,成本也低。但是随着信息数量的不断增长,访问量和数据量的飞速增长,以及系统业务的复杂 度增加,这种架构会造成服务器相应客户端的请求日益缓慢,并发量特别大的时候,还容易造成服务器直接崩溃。很明显这是由于服务器性能的瓶颈造成的问题,那么如何解决这种情况呢?
我们首先想到的可能是升级服务器的配置,比如提高 CPU 执行频率,加大内存等提高机 器的物理性能来解决此问题,但是我们知道摩尔定律的日益失效,硬件的性能提升已经不能满足日益提升的需求了。最明显的一个例子,天猫双十一当天,某个热销商品的瞬时访问量是极其庞大的,那么类似上面的系统架构,将机器都增加到现有的顶级物理配置,都是不能够满足需求的。那么怎么办呢?
上面的分析我们去掉了增加服务器物理配置来解决问题的办法,也就是说纵向解决问题的办法行不通了,那么横向增加服务器的数量呢?这时候集群的概念产生了,单个服务器解决不了,我们增加服务器的数量,然后将请求分发到各个服务器上,将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上,将负载分发到不同的服务器,也就是我们所说的负载均衡
4、动静分离
为了加快网站的解析速度,可以把动态页面和静态页面由不同的服务器来解析,加快解析速 度。降低原来单个服务器的压力。
二、Nginx使用
1、安装
1 准备
安装nginx服务器需要以下几个相关的依赖与nginx才可以完成安装
-
pcre
-
openssl
-
zlib
-
nginx
注意:预备环境应当要装好gcc c++与make(编译源码)
如果没有安装gcc环境可以运行以下命令对环境进行安装
yum install gcc gcc-c++
安装make环境如下
yum -y install gcc automake autoconf libtool make
2 pcre安装
百度下载 PCRE的源码包,也可以使用下面命令下载编译和安装 PCRE包:
#进入/usr/local目录将文件下载到这里 方便解压安装
cd /usr/local/
#下载
wget https://sourceforge.net/projects/pcre/files/pcre/8.43/pcre-8.43.tar.gz
#解压
tar -zxvf pcre-8.43.tar.gz
#进入pcre目录
cd pcre-8.43
#执行配置文件
./configure
# 开始编译
make
make install
# 可以查看当前版本, 显示版本表示安装成功
pcre-config --version
3 zlib、openssl
yum -y install make zlib zlib-devel gcc-c++ libtool openssl openssl-devel
当然也可以自己手动安装, 去官网下载相关的tar.gz压缩包解压和编译 步骤与pcre相同
#zlib
http://www.zlib.net/
#openssl
https://github.com/openssl/openssl
4 Nginx
将nginx服务器上传至linux系统中的 /usr/local/目录下
将上传至linux系统的tar.gz压缩包进行解压
tar -zxvf nginx-1.16.1.tar.gz
进入nginx服务器目录下进行安装编译
cd nginx-1.16.1
# 运行配置文件
./configure
# 编译
make && make install
查看/usr/local目录下多了一个nginx文件夹, 就是安装好的服务器及相关的启动信息等(sbin目录下)
5 启动Nginx
# 进入nginx目录下的sbin目录
cd nginx/sbin/
#启动
./nginx
可能会出现的错误
/usr/``local``/nginx/sbin/nginx: error ``while` `loading shared libraries: libpcre.so.1: cannot ``open` `shared object ``file``: No such ``file` `or directory
解决办法
# 根据上面的错误可以知道可能是没有lib导致的, 所以进入lib目录下创建软链接连接到lib库即可(以下是64位)
ln -s /lib64/libpcre.so.0.0.1 /lib64/libpcre.so.1
#查看运行情况
ps -aux | grep nginx
查看nginx的配置文件
如何才能查看nginx启动成功?
实际上访问本地的80端口就可以看到nginx的欢迎页
为什么是80端口和nginx的配置有关
#查看配置
cat /usr/local/nginx/conf/nginx.conf
外部访问 nginx
同样的想要外部能够访问nginx服务器要开启对应的nginx的监听端口
vim /etc/sysconfig/iptables
# 添加允许开放的端口
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
#重启防火墙
service iptables restart
2、常用命令
注意:要使用相关的nginx命令,必须进入到nginx所安装的目录下的/sbin目录
cd /usr/local/nginx/sbin
1 查看版本号
命令
./nginx -v
2 停止nginx
命令
./nginx -s stop
# 可以通过查看线程情况看是否停止
ps -ef |grep nginx
3 启动nginx
命令
./nginx
4 重载nginx
在有一些情况下我们可能会更改nginx的配置文件, 通过重新加载可以在不重启服务器的情况下让配置文件生效
./nginx -s reload
3、配置文件
1 配置文件所在位置
在nginx中的配置文件所在位置是安装目录下的conf目录中
cat /usr/local/nginx/conf/nginx.conf
2 配置文件解析
将所有#所注释的部分都删除,简化后大致如下
nginx.conf 配置文件分为三部分:
-
全局块
-
从配置文件开始到 events 块之间的内容,主要会设置一些影响nginx 服务器整体运行的配置指令,主要包括配置运行Nginx 服务器的用户(组)、允许生成的 worker process 数,进程 PID 存放路径、日志存放路径和类型以及配置文件的引入等。
-
比如第一行的内容 就是全局块中的配置
这是 Nginx 服务器并发处理服务的关键配置,worker_processes值越大,可以支持的并发处理量也越多,但是会受到硬件、软件等设备的制约
-
-
events块
-
events { worker_connections 1024; }
-
events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接,常用的设置包括是否开启对多work process下的网络连接进行序列化,是否允许同时接收多个网络连接,选取哪种事件驱动模型来处理连接请求,每个word process 可以同时支持的最大连接数等。
上述例子就表示每个 work process 支持的最大连接数为 1024
这部分的配置对 Nginx 的性能影响较大,在实际中应该灵活配置
-
-
http块
这算是 Nginx 服务器配置中最频繁的部分,代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里。
需要注意的是:http块也可以包括http全局块、server块。
-
http全局块
http全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。
-
server块
这块和虚拟主机有密切关系,虚拟主机从用户角度看,和一台独立的硬件主机是完全一样的,该技术的产生是为了 节省互联网服务器硬件成本。
每个 http 块可以包括多个 server 块,而每个 server 块就相当于一个虚拟主机
而每个 server 块也分为全局 server 块,以及可以同时包含多个 locaton 块。
1、全局 server 块
最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或IP配置。
2、 location 块
一个 server 块可以配置多个 location 块。
这块的主要作用是基于 Nginx 服务器接收到的请求字符串(例如 server_name/uri-string),对虚拟主机名称 (也可以是IP 别名)之外的字符串(例如 前面的 /uri-string)进行匹配,对特定的请求进行处理。地址定向、数据缓存和应答控制等功能,还有许多第三方模块的配置也在这里进行。
-
三、反向代理
1、实例一
需求:使用nginx反向代理,访问www.erran.com直接跳转到linux服务器的tomcat
- 先将tomcat成功部署到Linux服务器上, 并且防火墙开放8080端口
- 测试通过本地主机是否能够访问虚拟机的tomcat服务器
- 通过配置windows本地的hosts文件来限制 www.erran.com这个网址只能本地内访问指向虚拟机的地址
- hosts文件一般在windows系统的C:\\WINDOWS\\system32\\drivers\\etc位置
- 也可以直接通过WIN+R运行直接打开
1 打开tomcat
2 修改本地hosts文件
3 修改linux服务器上的nginx配置文件
#进入配置目录
cd /usr/local/nginx/conf/
#修改配置文件
vim nginx.conf
修改成功之后保存退出,记得proxy_pass配置完要用分号结尾
4 运行
#进入sbin目录
cd ..
cd sbin
# 启动nginx服务器
./nginx
运行结果
2、实例二
需求: 访问虚拟机9001端口的两个路径,分别转发到两个不同的tomca上
虚拟机IP:9001/edu 路径对应一个tomcat8081
虚拟机IP:9001/vod 路径对应一个tomcat8082
- 部署两个tomcat服务到linux系统上
- 修改tomcat的配置文件来更改tomcat的端口号
- 添加tomcat项目的测试文件以区分tomcat81和82
- 修改nginx的配置文件
实现过程
1 上传tomcat服务器到usr文件夹下
2 分别创建tomcat81和tomcat82文件,解压tomcat服务器
cd /usr/
mkdir tomcat81
mkdir tomcat82
# 拷贝tomcat到对应文件夹中
cp apache-tomcat-8.5.65.tar.gz /usr/tomcat81
cp apache-tomcat-8.5.65.tar.gz /usr/tomcat82
# 解压
tar -zxvf apache-tomcat-8.5.65.tar.gz
3 修改配置文件
# 进入tomcat81、tomcat82的conf目录
# 修改server.xml文件
修改server.xml文件的几个端口
tomcat81 : 8081 8019
tomcat81 : 8082 8029
4 修改nginx的配置文件, 并且开放9001端口
#进入配置文件目录
cd /usr/local/nginx/conf/
#修改
vim nginx.conf
#如果nginx没启动则直接启动
#如果nginx启动了则保存退出后用reload指令重新加载nginx配置
./nginx -s reload
关于location指令说明
该指令用于匹配 URL。 语法如下:
location [= | ~ | ~* | ^~] uri {
#具体配置
}
1、= :用于不含正则表达式的 uri 前,要求请求字符串与 uri 严格匹配,如果匹配 成功,就停止继续向下搜索并立即处理该请求。
2、~:用于表示 uri 包含正则表达式,并且区分大小写。
3、~*:用于表示 uri 包含正则表达式,并且不区分大小写。
4、^~:用于不含正则表达式的 uri 前,要求 Nginx 服务器找到标识 uri 和请求字 符串匹配度最高的 location 后,立即使用此 location 处理请求,而不再使用 location 块中的正则 uri 和请求字符串做匹配。
注意:如果 uri 包含正则表达式,则必须要有 ~ 或者 ~* 标识
5 分别往81和82端口的tomcat服务器中添加测试项目
6 访问测试
四、负载均衡
负载均衡(Load Balance),意思是将负载(工作任务,访问请求)进行平衡、分摊到多个操作单元(服务器,组件)上进行执行。是解决高性能,单点故障(高可用),扩展性(水平伸缩)的终极解决方案。
随着互联网信息的爆炸性增长,负载均衡(load balance)已经不再是一个很陌生的话题, 顾名思义,负载均衡即是将负载分摊到不同的服务单元,既保证服务的可用性,又保证响应 足够快,给用户很好的体验。快速增长的访问量和数据流量催生了各式各样的负载均衡产品, 很多专业的负载均衡硬件提供了很好的功能,但却价格不菲,这使得负载均衡软件大受欢迎, nginx 就是其中的一个,在 linux 下有 Nginx、LVS、Haproxy 等等服务可以提供负载均衡服务
1、负载均衡实例
1 准备工作
- 部署两个tomcat服务到linux系统上
- 修改tomcat的配置文件来更改tomcat的端口号
- 添加tomcat项目的测试文件以区分tomcat81和82
- 修改nginx的配置文件
实现效果:访问服务器中的edu项目实现负载均衡,81和82端口平均分配访问
2 实现步骤
准备工作完成后修改nginx的配置文件
将要修改的内容包含在http块中
- upstream 里面配置的是负载均衡的内容(myserver是负载均衡服务器名称)
- 将proxy_pass属性更改为代理服务器
3 分配方式
在nginx中的处理方式有好几种, 可以在nginx.conf中进行配置
- 轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器 down 掉,能自动剔除。
- weight
weight代表权,重默认为1,权重越高被分配的客户端越多
指定轮询几率,weight 和访问比率成正比,用于后端服务器性能不均的情况。 例如:
upstream myserver{
server 192.168.110.128:8081 weight=10;
server 192.168.110.128:8082 weight=10;
}
- ip_hash
每个请求按访问 ip 的 hash 结果分配,这样每个访客固定访问一个后端服务器,可以解决 session 的问题
upstream myserver{
ip_hash;
server 192.168.110.128:8081;
server 192.168.110.128:8082;
}
- fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstream myserver{
server 192.168.110.128:8081;
server 192.168.110.128:8082;
fair;
}
五、动静分离
Nginx 动静分离简单来说就是把动态跟静态请求分开,不能理解成只是单纯的把动态页面和静态页面物理分离。严格意义上说应该是动态请求跟静态请求分开,可以理解成使用 Nginx 处理静态页面,Tomcat 处理动态页面。动静分离从目前实现角度来讲大致分为两种:
-
一种是纯粹把静态文件独立成单独的域名,放在独立的服务器上,也是目前主流推崇的方案;
-
另外一种方法就是动态跟静态文件混合在一起发布,通过nginx来分开。
通过 location 指定不同的后缀名实现不同的请求转发。通过 expires 参数设置,可以使浏览器缓存过期时间,减少与服务器之前的请求和流量。
具体 Expires 定义:是给一个资 源设定一个过期时间,也就是说无需去服务端验证,直接通过浏览器自身确认是否过期即可, 所以不会产生额外的流量。
此种方法非常适合不经常变动的资源。(如果经常更新的文件, 不建议使用 Expires 来缓存),我这里设置 3d,表示在这 3 天之内访问这个 URL,发送 一个请求,比对服务器该文件最后更新时间没有变化,则不会从服务器抓取,返回状态码 304,如果有修改,则直接从服务器重新下载,返回状态码 200。
1、准备工作
-
与上相同配置好tomcat服务器
-
可以直接在linux系统中创建一个文件夹用来放置相关的静态文件(回头会由nginx转发)
cd /usr/local/
mkdir static
-
随便上传一些静态资源, 比如 jpg、png、avi、html、js、css
-
配置nginx.conf文件
2、动静分离实例
1 资源准备
2 配置nginx.conf
cd /usr/local/nginx/conf/
vim nginx.conf
location / {
proxy_pass http://myserver;
}
location ~ .*\\.(html|gif|jpg|png|bmp|swf|jpeg)$ {
root /usr/local/static;
}
#配置成功之后重启nginx服务器
cd /usr/local/nginx/sbin/
./nginx -s reload
3、测试访问
六、高可用集群
大家知道NGINX作为反向代理服务器可以实现负载均衡,同时也可以作为静态文件服务器,它的特点就是并发支持大,单机可同时支持3万并发,现在很多网站都把NGINX作为网关入口来统一调度分配后端资源。但是如果NGINX宕机了,就会导致整个后台服务无法使用;或者当并发量真的非常大时,达到十万级别时,一台NGINX还是有极限的,
所以这个时候就需要针对NGINX进行主从备份保证服务高可用、集群来分担并发压力。
目前市面上主流的高可用集群解决方案是: nginx+keepalived
1、准备工作
- 需要两台nginx服务器(所以需要两个Linux虚拟机)
- 两台服务器都安装Keepalived
- 两台Linux都安装好nginx
2、高可用实例
-
先确保两台Linux服务器都安装好nginx
-
在两台服务器安装 keepalived
#快速安装指令
yum install keepalived -y
安装之后,在 etc 里面生成目录 keepalived,有文件 keepalived.conf
- 配置Keepalived
在/etc/keepalived/ 文件夹下,配置内容如下
! Configuration File for keepalived
#全局配置
global_defs {
#通知邮件当发生事件的时候
notification_email {
acassen@firewall.loc
failover@firewall.loc
sysadmin@firewall.loc
}
notification_email_from Alexandre.Cassen@firewall.loc
smtp_server 192.168.110.128 #指定发送邮件的smtp服务器。
smtp_connect_timeout 30
router_id LVS_DEVEL # 路由主机名 可以通过/etc/host查看
}
#vrrp实例
vrrp_instance VI_1 {
state MASTER # 备份服务器上将 MASTER 改为 BACKUP
interface eth0 # 网卡 用ifconfig查看
virtual_router_id 51 # 主、备机的 virtual_router_id 必须相同
priority 100 # 主、备机取不同的优先级,主机值较大,备份机值较小
advert_int 1 # 检查的间隔时间
authentication { #身份认证方式
auth_type PASS #认证方式,支持PASS和AH,官方建议使用PASS
auth_pass 1111 #认证密码
}
virtual_ipaddress {
192.168.110.135 # 虚拟ip 和 真实ip在同网段
}
}#脚本配置
vrrp_script chk_http_port {
script "/usr/local/src/nginx_check.sh" interval 2 #(检测脚本执行的间隔)
weight 2
}
- 添加nginx_check.sh文件到 之前keepalived的配置文件所指定的目录下
#!/bin/bash
A=`ps -C nginx –no-header |wc -l`
if [ $A -eq 0 ];then
/usr/local/nginx/sbin/nginx
sleep 2
if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
killall keepalived
fi
fi
- 在两台服务器都添加完以上的keepalived文件和nginx检查文件后, 启动keepalived服务,启动nginx
#启动keepalived
service keepalived start
#启动nginx
cd /usr/local/nginx/sbin/
./nginx
测试
-
直接访问虚拟IP看看是否能够到达指定主服务器
-
可以成功到达后尝试将主服务器的服务关闭
service keepalived stop
-
看看是否能够成功切换到备份服务器
3、VRRP协议详解&Keepalived配置解析
1 概述
虚拟路由冗余协议 VRRP(Virtual Router Redundancy Protocol)通过把几台路由设备联合组成一台虚拟的路由设备,使用一定的机制保证当主机的下一跳路由器出现故障时,及时将业务切换到备份路由器,从而保持业务的连续性和可靠性。
2 示意图
3 工作过程
VRRP 备份组中的交换机根据优先级选举出 Master。Master交换机通过发送ARP 报文,将虚拟MAC地址通知给与它连接的设备或者主机,从而承担报文转发任务。
Master 交换机周期性向备份组内所有 Backup 交换机发送 VRRP 通告报文,以公布其配 置信息(优先级等)和工作状况。
如果 Master 交换机出现故障,VRRP 备份组中的 Backup 交换机将根据优先级重新选举 新的 Master。VRRP 备份组状态切换时,Master 交换机由一台设备切换为另外一台设备,新的Master 交换机会立即发送携带虚拟路由器的虚拟MAC地址和虚拟IP(Virtual IP以下简称VIP)地址信息的ARP报文,刷新与它连接的主机或设备中的MAC表项,从而把用户流量引到新的 Master 交换机上来,整个过程对用户完全透明。
七、Nginx工作原理
master-workers 的机制的好处
首先,对于每个 worker 进程来说,独立的进程,不需要加锁,所以省掉了锁带来的开销, 同时在编程以及问题查找时,也会方便很多。其次,采用独立的进程,可以让互相之间不会 影响,一个进程退出后,其它进程还在工作,服务不会中断,master 进程则很快启动新的 worker 进程。当然,worker 进程的异常退出,肯定是程序有 bug 了,异常退出,会导致当 前 worker 上的所有请求失败,不过不会影响到所有请求,所以降低了风险。
需要设置多少个 worker
Nginx 同 redis 类似都采用了 io 多路复用机制,每个 worker 都是一个独立的进程,但每个进 程里只有一个主线程,通过异步非阻塞的方式来处理请求, 即使是千上万个请求也不在话 下。每个 worker 的线程可以把一个 cpu 的性能发挥到极致。所以 worker 数和服务器的 cpu 数相等是最为适宜的。设少了会浪费 cpu,设多了会造成 cpu 频繁切换上下文带来的损耗
#设置 worker 数量。
worker_processes 4
#work 绑定 cpu(4 work 绑定 4cpu)
worker_cpu_affinity 0001 0010 0100 1000
#work 绑定 cpu (4 work 绑定 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。因为作为反向代理服务器,每个并发会建立与客户端的连接和与后端服 务的连接,会占用两个连接
以上是关于Nginx从入门到应用详解的主要内容,如果未能解决你的问题,请参考以下文章
Nginx从入门到精通Nginx配置文件说明及Nginx主要应用