Nginx
Nginx 简介
Nginx 概述
Nginx (“engine x”) 是一个高性能的 HTTP 和反向代理服务器,特点是占有内存少,并发能力强,事实上 nginx 的并发能力确实在同类型的网页服务器中表现较好,中国大陆使用 nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等。
Nginx 作为 web 服务器
Nginx 可以作为静态页面的 web 服务器,同时还支持 CGI 协议的动态语言,比如 perl、php等。但是不支持 java。Java 程序只能通过与 tomcat 配合完成。Nginx 专为性能优化而开发,性能是其最重要的考量,实现上非常注重效率 ,能经受高负载的考验,有报告表明能支持高达 50,000 个并发连接数。
正向代理
Nginx 不仅可以做反向代理,实现负载均衡。还能用作正向代理来进行上网等功能。正向代理:如果把局域网外的 Internet 想象成一个巨大的资源库,则局域网中的客户端要访问 Internet,则需要通过代理服务器来访问,这种代理服务就称为正向代理。

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

负载均衡
客户端发送多个请求到服务器,服务器处理请求,有一些可能要与数据库进行交互,服务器处理完毕后,再将结果返回给客户端。 这种架构模式对于早期的系统相对单一,并发请求相对较少的情况下是比较适合的,成本也低。但是随着信息数量的不断增长,访问量和数据量的飞速增长,以及系统业务的复杂度增加,这种架构会造成服务器相应客户端的请求日益缓慢,并发量特别大的时候,还容易造成服务器直接崩溃。很明显这是由于服务器性能的瓶颈造成的问题,那么如何解决这种情况呢?
我们首先想到的可能是升级服务器的配置,比如提高 CPU 执行频率,加大内存等提高机器的物理性能来解决此问题,但是我们知道摩尔定律的日益失效,硬件的性能提升已经不能满足日益提升的需求了。最明显的一个例子,天猫双十一当天,某个热销商品的瞬时访问量是极其庞大的,那么类似上面的系统架构,将机器都增加到现有的顶级物理配置,都是不能够满足需求的。那么怎么办呢?
上面的分析我们去掉了增加服务器物理配置来解决问题的办法,也就是说纵向解决问题的办法行不通了,那么横向增加服务器的数量呢?这时候集群的概念产生了,单个服务器解决不了,我们增加服务器的数量,然后将请求分发到各个服务器上,将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上,将负载分发到不同的服务器,也就是我们所说的负载均衡。

动静分离
为了加快网站的解析速度,可以把动态页面和静态页面由不同的服务器来解析,加快解析速度。降低原来单个服务器的压力。

Nginx 安装
下载nginx
进入 nginx 官网,下载 http://nginx.org/



安装nginx依赖
在安装nginx前首先要确认系统中安装了gcc、pcre-devel、zlib-devel、openssl-devel
linux下检查是否安装过某软件包
rpm包安装的,可以用 rpm -qa 看到,如果要查找某软件包是否安装,用:
1 | rpm -qa | grep "软件或者包的名字" |
以deb包安装的,可以用 dpkg -l 看到。如果是查找指定软件包,用 :
1 | dpkg -l | grep "软件或者包的名字" |
yum方法安装的,可以用 yum list installed 查找,如果是查找指定包,用 :
1 | yum list installed | grep "软件名或者包名" |
举例:查看是否安装了gcc
1 | yum list installed | grep "gcc" |

这里可以确认我们没有安装gcc
1 | yum -y install gcc |

再次执行查找命令

安装命令:
1 | yum -y install gcc pcre-devel zlib-devel openssl openssl-devel |

将下载好的nginx软件包,移动到/usr/local/下。

解压
1 | tar -zxvf nginx-1.17.10.tar.gz |
进入nginx目录
1 | cd nginx-1.17.10 |
配置
1 | ./configure --prefix=/usr/local/work/nginx |
make
1 | make && make install |
安装成功之后,在 /usr/local 文件夹下,会有一个 nginx 文件夹

在这个文件夹中的 sbin 目录下,会有一个 nginx 启动命令

删除源码和压缩包(如果是make安装,源码最好放在 /usr/local/src 下面)
测试启动
在 /sbin 目录下 运行
1 | ./nginx |

查看进程
1 | ps -ef|grep nginx |

查看 nginx 相应配置
1 | vim /usr/local/nginx/conf/nginx.conf |

此时的服务已经启动,并且在localhost:80这个地址上,但是由于linux防火墙设置,这个端口访问不到
设置防火墙开放端口
查看开放的端口号
1 | firewall-cmd --list-all |
设置开放的端口号(这里设置的是80端口)
1 | firewall-cmd --add-service=http --permanent |
重启防火墙
1 | firewall-cmd --reload |
再访问localhost:80

Nginx 常用的命令和配置文件
常用命令
(由于没有配置环境变量,所有的命令都需要在 /usr/local/nginx/sbin 目录下执行 )
启动命令
1 | ./nginx |
关闭命令
1 | ./nginx -s stop |
重新加载命令(修改 nginx.conf 配置文件之后,可以使用此命令,重启 nginx)
1 | ./nginx -s reload |
配置文件
nginx 安装目录下,其默认的配置文件都放在这个目录的 conf 目录下,而主配置文件 nginx.conf 也在其中,后续对 nginx 的使用基本上都是对此配置文件进行相应的修改。
配置文件中有很多#, 开头的表示注释内容,我们去掉所有以 # 开头的段落,精简之后的内容如下:

根据上述文件,我们可以很明显的将 nginx.conf 配置文件分为三部分:
第一部分:全局块
从配置文件开始到 events 块之间的内容,主要会设置一些影响 nginx 服务器整体运行的配置指令,主要包括配置运行 Nginx 服务器的用户(组)、允许生成的 worker process 数,进程 PID 存放路径、日志存放路径和类型以及配置文件的引入等。
比如上面第一行配置的:
1 | worker_processes 1; |
这是 Nginx 服务器并发处理服务的关键配置,worker_processes 值越大,可以支持的并发处理量也越多,但是会受到硬件、软件等设备的制约。
第二部分:events 块
比如上面的配置:
1 | events { |
events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接,常用的设置包括是否开启对多 work process 下的网络连接进行序列化,是否允许同时接收多个网络连接,选取哪种事件驱动模型来处理连接请求,每个 word process 可以同时支持的最大连接数等。
上述例子就表示每个 work process 支持的最大连接数为 1024。 这部分的配置对 Nginx 的性能影响较大,在实际中应该灵活配置。
第三部分:http 块
1 | http { |
这算是 Nginx 服务器配置中最频繁的部分,代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里。
需要注意的是:http 块也可以包括 http 全局块、server 块。
① http 全局块
http 全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。
② server 块
这块和虚拟主机有密切关系,虚拟主机从用户角度看,和一台独立的硬件主机是完全一样的,该技术的产生是为了节省互联网服务器硬件成本。每个 http 块可以包括多个 server 块,而每个 server 块就相当于一个虚拟主机。而每个 server 块也分为全局 server 块,以及可以同时包含多个 locaton 块。
- 全局 server 块
最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或 IP 配置。
- location 块
一个 server 块可以配置多个 location 块。这块的主要作用是基于 Nginx 服务器接收到的请求字符串(例如server_name/uri-string),对虚拟主机名称(也可以是 IP 别名)之外的字符串(例如 前面的 /uri-string)进行匹配,对特定的请求进行处理。地址定向、数据缓存和应答控制等功能,还有许多第三方模块的配置也在这里进行。
Nginx 配置实例反向代理
反向代理实例一
实现效果:打开浏览器,在浏览器地址栏输入 www.mogon.com 直接跳转到 linux 系统 tomcat 主页面
准备工作
- 在 linux 系统上安装一个 tomcat 并使用端口 8080 (本地 linux 服务器IP为 10.0.7.210)
- 启动一个 tomcat,在 windows 系统中,浏览器地址栏输入 10.0.7.210:8080,出现如下界面:

(这里是搭在公司服务器上,所以ip是10.0.7.210,而且8080端口也需要linux防火墙进行开放,具体方法同上,这里分别开了8080 8081 8082三个端口)

- 通过修改本地 host 文件,将 www.local-nginx.com 映射到 10.0.7.210,如下:

- 配置完成之后,我们便可以通过 www.local-nginx.com:8080 访问到第一步出现的 Tomcat 初始界面。

- 现在我们要得到的结果是,访问 linux 中 nginx 的 80 端口,再通过 nginx 转发给 8080 端口,需要配置 nginx.conf,并重启 nginx 服务

(注意:此处 server_name 是 nginx 所在服务器的IP地址,如果该服务器申请了域名,也可以填域名,proxy_pass 为转发的地址和端口,只要是和服务器在同一个网段,或者用服务器能ping通的地址,都可以,此处由于 tomcat 搭在了 nginx 所在的服务器上,所以使用 127.0.0.1:8080,还需要注意的一点是,proxy_pass 前面必须有 http:// )
- 访问 www.local-nginx.com 得到结果

心得:此处需要说明的是,其实服务器的8080 8081 8082这3个端口,不需要对外暴露,nginx 就是解决类问题的,只要将nginx所在的端口暴露出来就可以,想要访问其他端口,就可以通过配置 nginx.conf,来将请求转发给其他端口,这就是简单的反向代理,而这里暴露8080 8081 8082是为了演示实验的请求走向
反向代理实例二
此时我们只启动了1个 tomcat 服务,现在我们把3个 tomcat 服务全都开启,首先需要配置 tomcat 端口

(注意:这里是 tomcat-002 的端口,tomcat-003配置成8007 8082 8011)

(此时3个 tomcat 都能够正常启动,说明配置文件修改没问题)
- 在 tomcat-001 的 webapps 下创建文件夹 001 并创建一个 index.html 内容如下

- 同样在 tomcat-002 的 webapps 下创建文件夹 002 并创建一个 index.html 内容为
1 | <h1>Tomcat-002</h1> |
(tomcat-003 的也一样)
- 修改 nginx.conf 配置文件

- 重启 tomcat 服务和 nginx 服务
- 在 windows 浏览器中分别输入
1 | http://www.local-nginx.com/001/index.html |
显示结果如下



这就是根据访问路径不同,转发给不同的端口
location 指令说明 (该指令用于匹配 URL)
语法如下:
1 | location [ = | ~ | ~* | ^~ ] uri { |
- = 用于不含正则表达式的 uri 前,要求请求字符串与 uri 严格匹配,如果匹配成功,就停止继续向下搜索并立即处理该请求。
- ~ 用于表示 uri 包含正则表达式,并且区分大小写。
- ~* 用于表示 uri 包含正则表达式,并且不区分大小写。
- ^~ 用于不含正则表达式的 uri 前,要求 Nginx 服务器找到标识 uri 和请求字符串匹配度最高的 location 后,立即使用此 location 处理请求,而不再使用 location 块中的正则 uri 和请求字符串做匹配。
注意:如果 uri 包含正则表达式,则必须要有 ~ 或者 ~* 标识。
Nginx 配置实例负载均衡
负载均衡实例
实现效果:配置负载均衡
准备工作:分别在3个 tomcat 下的 webapps 中创建相同的文件夹lb,此文件夹下分别创建 index.html 内容分别为 :
1 | <h1>Tomcat-001</h1> |

在 nginx 的配置文件中,进行负载均衡配置

(选用随机访问的策略)
- 重启 nginx 和 tomcat 后,在浏览器中访问 http://www.local-nginx.com/lb/index.html 会随机分配到3个 tomcat 中,这里先后测试 6 次访问结果,如下:

负载均衡策略
以上就是最基本的负载均衡实例,但这不足以满足实际需求;目前Nginx服务器的upstream模块支持6种方式的分配:
| 轮询 | 默认方式 |
|---|---|
| weight | 权重方式 |
| ip_hash | 依据ip分配方式 |
| least_conn | 最少连接方式 |
| fair(第三方) | 响应时间方式 |
| url_hash(第三方) | 依据URL分配方式 |
| random | 随机分配方式 |
轮询
最基本的配置方法,上面的例子就是轮询的方式,它是 upstream 模块默认的负载均衡默认策略。每个请求会按时间顺序逐一分配到不同的后端服务器。
有如下参数:
| fail_timeout | 与max_fails结合使用。 |
|---|---|
| max_fails | 设置在fail_timeout参数设置的时间内最大失败次数,如果在这个时间内,所有针对该服务器的请求都失败了,那么认为该服务器会被认为是停机了, |
| fail_time | 服务器会被认为停机的时间长度,默认为10s。 |
| backup | 标记该服务器为备用服务器。当主服务器停止时,请求会被发送到它这里。 |
| down | 标记服务器永久停机了。 |
注意:
- 在轮询中,如果服务器down掉了,会自动剔除该服务器。
- 缺省配置就是轮询策略。
- 此策略适合服务器配置相当,无状态且短平快的服务使用。
weight
权重方式,在轮询策略的基础上指定轮询的几率。例子如下:
1 | upstream mogonserver { |
在该例子中,weight 参数用于指定轮询几率,weight的默认值为1,;weight的数值与访问比率成正比,比如 8080 端口所在的 tomcat 被访问的几率为其他服务器的两倍。
注意:
- 权重越高分配到需要处理的请求越多。
- 此策略可以与 least_conn 和 ip_hash 结合使用。
- 此策略比较适合服务器的硬件配置差别比较大的情况。
ip_hash
指定负载均衡器按照基于客户端 IP 的分配方式,这个方法确保了相同的客户端的请求一直发送到相同的服务器,以保证 session 会话。这样每个访客都固定访问一个后端服务器,可以解决 session 不能跨服务器的问题。
1 | #动态服务器组 |
注意:
- 在nginx版本1.3.1之前,不能在ip_hash中使用权重(weight)。
- ip_hash 不能与 backup 同时使用。
- 此策略适合有状态服务,比如 session。
- 当有服务器需要剔除,必须手动 down 掉。
least_conn
把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端,使它们的负载大致相同;但是,有些请求占用的时间很长,会导致其所在的后端负载较高。这种情况下,least_conn这种方式就可以达到更好的负载均衡效果。
1 | upstream mogonserver { |
注意:
- 此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。
第三方策略
第三方的负载均衡策略的实现需要安装第三方插件。
fair
按照服务器端的响应时间来分配请求,响应时间短的优先分配。
1 | upstream mogonserver { |
url_hash
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,要配合缓存命中来使用。同一个资源多次请求,可能会到达不同的服务器上,导致不必要的多次下载,缓存命中率不高,以及一些资源时间的浪费。而使用 url_hash ,可以使得同一个 url(也就是同一个资源请求)会到达同一台服务器,一旦缓存住了资源,再此收到请求,就可以从缓存中读取。
1 | upstream mogonserver { |
random
就如上述实例中,随机分配请求
1 | upstream mogonserver { |
Nginx 配置实例动静分离
动静分离实例
准备工作:在 linux 服务器中,新建目录 /mgfiles/www 和 /mgfiles/images 并在其中放入 index.html 和 一个图片 index.jpg :


- 修改 nginx 配置文件,在 server 中加入:
1 | location /www/ { |
- 重启 nginx 服务
- 浏览器中输入:http://www.local-nginx.com/www/









