目录
一、Nginx是什么
Nginx的优势
二、Nginx的下载及安装
1.安装路径中不要存在中文
2.第一次运行建议使用超级管理员的身份启动
3.打开任务管理器
4.尝试访问
5.基本命令
三、Nginx反向代理原理
四、Nginx的入门配置
五、正向代理与反向代理的区别
六、Nginx实现域名代理配置
七、负载均衡策略准备工作
1.什么是负载均衡?
2.负载均衡策略简单应用
八、Nginx负载均衡策略
九、Nginx其它常用的配置属性
十、tomcat高可用实现
nginx健康监测机制
被动监测
主动监测
FAQ问题分析
一、Nginx多启动问题
二、80端口被占用问题
三、启动Nginx时失败问题
Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器,同时也提供IMAP/POP3/SMTP服务,Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。
并发能力强,理论上每秒支持并发访问数量5万次,实际值是每秒2-3万次。
占用的内存小,因为Nginx由C语言开发,运行内存不超过2M。
Nginx官网:
http://nginx.org/en/download.html
目的为了获取nginx访问权限
正常情况下会存在以下两个Nginx进程
一共是两个进程,内存占用量大的是主进程,其次是守护进程,守护进程可以防止nginx的意外关闭,除非守护进程结束,主进程才能被结束。
初次安装成功后,默认监听的端口是80,监听的域名是localhost
window系统下,请在Nginx安装根目录下打开命令窗口
1).start nginx
2).nginx -s reload //重启
3).nginx -s stop
4)taskkill /f /im nginx.exe 利用windows管理器 杀进程
在执行stop命令的时候会失败,因为nginx存在一个守护进程,可以先关闭守护线程在关闭主进程,也可以使用window系统的taskkill命令强制关闭。
1.用户访问资源时,发送请求,代理服务器拦截用户请求,根据代理服务器中的配置信息,进行路径的动态切换
3.将路径转化完成之后,由代理服务器代替用户访问真实的数据资源
4.代理服务器获取真实服务器的数据
5.代理服务器将结果返回给用户
1.打开nginx的conf目录下的nginx.conf文件
2.添加需要的配置
http{
#配置图片服务器
#每一个 server 都是一个反向代理
server {
listen 80; #监听的端口
server_name wph.img.com; #监听的域名
# / 代表拦截所有的请求路径
location / {
#root 是一个关键字,表示代理的是一个文件路径
#其中还有关键字:proxy_pass表示代理的是一个链接的路径
root E:/vip/img;
}
}
}
以上配置的意思是:当用户访问域名为 wph.img.com 并且端口是 80 的时候,代理服务器会拦截到用户的请求,将请求路径的域名替换为E:/vip/img文件的路径,最后返回结果给用户。
此外,还需要修改系统中的hosts文件,快速解析域名
如不配置,浏览器默认会到DNS服务器上解析域名
3.修改hosts文件
找到hosts文件
添加配置内容
#配置图片服务器
127.0.0.1 wph.img.com
反向代理服务器位于用户与目标服务器之间,但是对于用户而言,用户不了解真实的服务器地址,服务器了解用户的信息,反向代理服务器就相当于目标服务器,即用户直接访问反向代理服务器就可以获得目标服务器的资源。同时,用户不需要知道目标服务器的地址,也无须在用户端作任何设定。反向代理服务器通常可用来作为Web加速,即使用反向代理作为Web服务器的前置机来降低网络和服务器的负载,提高访问效率
1.反向代理服务器位于用户与目标服务器之间.
2.但是对于用户而言,反向代理服务器就相当于目标服务器,即用户直接访问反向代理服务器就可以获得目标服务器的资源.
3.用户不了解真实的服务器地址,服务器了解用户的信息.
4.反向代理服务是服务器端代理,保护真实的服务器资源.
存在反向代理就存在正向代理,正向代理,意思是一个位于客户端和原始服务器之间的代理服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。
1.代理服务器位于用户和服务器之间
2.用户明确的知道服务器地址,由代理服务器代为请求
3.服务器以为获取的数据的方就是代理服务器
4.正向代理是客户端代理
在nginx,conf文件中添加配置
#配置后台管理服务器
server{
listen 80;
#项目的访问域名
server_name wph.vip.com;
# / 代表拦截所有请求路径
location / {
#root是反向代理的是文件路径
#proxy_pass代理的是一个链接的路径
proxy_pass http://127.0.0.1:8085;
}
}
修改配置文件之后,需要再次重启Nginx
如果我们的项目有一个服务器,那么,当服务器宕机后,用户也就无法继续访问。我们基于负载均衡,将项目部署到多台服务器上,提升项目抗击高并发的能力。
依靠Nginx可以通过配置文件,配置多台服务器,用户访问服务器的时候,通过配置文件的信息,让用户可以访问不同的服务器,减少单台服务器的访问压力。
1)在项目打包之前,修改yml配置文件中的server.port端口号
2)修改完成后项目打包
3)以此类推,每次修改完端口号后再打包
1.轮询策略
在nginx.conf配置文件中,如下可实现轮询策略,会根据配置的顺序
#配置后台管理服务器
server {
listen 80;
server_name wph.vip.com;
# /代表拦截所有的请求路径
location / {
#代理的是请求路径
#proxy_pass http://127.0.0.1:8091;
proxy_pass http://wphWindows;
}
}
#tomcat集群配置 windows集群 upstream 集群的定义
#默认规则 轮询策略
upstream wphWindows{
server 127.0.0.1:8091;
server 127.0.0.1:8092;
server 127.0.0.1:8093;
}
2.权重策略
根据配置,指定某些服务器多进行一些响应,一般会将性能优的服务器配置更高的权重。
#tomcat集群配置 windows集群 upstream 集群的定义
#默认规则 轮询策略
upstream jtWindows {
server 127.0.0.1:8081 weight=6;
server 127.0.0.1:8082 weight=3;
server 127.0.0.1:8083 weight=1;
}
3.IPHASH
由于是多台服务器,用户的信息每次都需要保存,不能保证数据的一致性,利用IPHASH策略,可以将用户的IP地址与tomcat服务器进行绑定。
#tomcat集群配置 windows集群 upstream 集群的定义
#默认规则 轮询策略
upstream jtWindows {
ip_hash;
server 127.0.0.1:8081 weight=6;
server 127.0.0.1:8082 weight=3;
server 127.0.0.1:8083 weight=1;
}
使用IPHASH的弊端:
1.如果tomcat服务器后台宕机,则直接影响用户的使用
2.如果使用IPhash方式,则可能导致负载不均的现象
综上所述,IPhash一般不会出现在上线的项目中,可以在测试时使用。
down属性
Nginx假如发现一台tomcat服务器宕机,在一段时间内,依然继续尝试访问,这显然是不可以的,可以在对应的配置文件中写上down属性,被标识的服务器,Nginx将不会再次访问。
#tomcat集群配置 windows集群 upstream 集群的定义
#默认规则 轮询策略
upstream jtWindows {
#ip_hash;
server 127.0.0.1:8091 down;
server 127.0.0.1:8092;
server 127.0.0.1:8093;
}
backup属性
该属性配置标识该服务器为备用机,正常情况下用户不会访问备用机,只有当主机遇忙,或者主机宕机时才会访问。
#tomcat集群配置 windows集群 upstream 集群的定义
#默认规则 轮询策略
upstream jtWindows {
#ip_hash;
server 127.0.0.1:8091;
server 127.0.0.1:8092;
server 127.0.0.1:8093 backup;
}
如果tomcat服务器宕机,可以通过程序实现自动的检测,如果发现服务器宕机,则自动的标识为down(内存中), 在指定的时间内用户不会再次去访问故障机.只有到了下一个周期才会去尝试访问故障机是否可用。
#配置后台管理服务器
server {
listen 80;
server_name wph.vip.com;
# /代表拦截所有的请求路径
location / {
#代理的是请求路径
#proxy_pass http://127.0.0.1:8091;
proxy_pass http://wphWindows;
#请求链接的超时时间
proxy_connect_timeout 1;
#如果读取服务器资源时 不能及时响应,则超时
proxy_read_timeout 1;
#向服务器发送数据时的超时时间
proxy_send_timeout 1;
}
}
#tomcat集群配置 windows集群 upstream 集群的定义
#默认规则 轮询策略
upstream wphWindows {
#ip_hash;
server 127.0.0.1:8091 max_fails=1 fail_timeout=60s;
server 127.0.0.1:8092 max_fails=1 fail_timeout=60s;
server 127.0.0.1:8093 max_fails=1 fail_timeout=60s;
}
当Nginx认为一台应用服务器不能被访问的时候,它会暂时停止向这台应用上面分发请求。直到Nginx认为该应用服务器可以再次被访问的时候才会再向这台应用服务器上面分发请求。
要实现对应用服务器的监测,需要通过两个参数来帮助。
fail_timeout——该参数表示停止分发请求至该应用服务器的时间。也就是说,如果Nginx认为一台应用服务器不能被访问了,则Nginx就会停止向这台应用服务器上分发请求。那需要多长时间Nginx才会认为该服务器可以被访问从而向其分发请求呢。这就需要通过该参数来设置这个时间了。
max_fails——设置访问失败的最大次数。当Nginx向一台服务器分发请求,如果失败的次数达到该参数设置的数量,则Nginx认为该应用服务器不能访问。在接下来的请求就不会再发给该应用服务器。直到达到fail_timeout设置的时间才会再次向这台应用分发请求。
对于fail_timeout和max_fails的默认值分别为10s和1次。也就是说,当Nginx向一台应用服务器发送请求,如果失败则认为该应用服务器不可访问,接下来的10s中请求不再分发给该应用服务器,直到10s以后会再次将请求分发给该应用服务器。
#tomcat集群配置 windows集群 upstream 集群的定义
#默认规则 轮询策略
upstream wphWindows {
server 127.0.0.1:8091 max_fails=1 fail_timeout=60s;
server 127.0.0.1:8092 max_fails=1 fail_timeout=60s;
server 127.0.0.1:8093 max_fails=1 fail_timeout=60s;
}
由Nginx定期的向每台应用服务器发送特殊的请求,来监测应用服务器是否可以正常访问。这种方式称为主动监测。需要指出的是,主动检测指令health_check目前只有nginx商业版本才提供。
为了实现主动监测这种方式,我们需要在Nginx负载均衡的配置文件中加入health_check指令。除此之外,我们还需要在设置应用服务器信息的组里加入zone指令
#配置后台管理服务器
server {
listen 80;
server_name wph.vip.com;
location / {
#代理的是请求路径
#proxy_pass http://127.0.0.1:8091;
health_check;
}
}
#tomcat集群配置 windows集群 upstream 集群的定义
#默认规则 轮询策略
upstream wphWindows {
zone wphWindows 64k
server 127.0.0.1:8091
server 127.0.0.1:8092
server 127.0.0.1:8093
}
在这里我们设置了一组应用服务器。通过一个单一的location,将所有的请求都分发到这组应用服务器上。在这种情况下,每隔5s Nginx Plus就会向每一台应用服务器发送’/’请求。任何一台应用服务器连接错误或者响应超时亦或者是被代理的服务器响应了一个状态码2xx或者是3xx,health_check机制就会认为是失败的。如果health_check失败,那么Nginx Plus就不再向这台应用服务器分发访问请求。
zone指令定义了一块内存空间。这块空间存储在各个工作进程中共享的运行环境的状态和应用服务器组的配置信息。这块空间应该根据实际情况尽量申请的大一些,要保证能存下这些信息。
如果Nginx启动了多个,那么之后做的配置都不会生效,因为配置以第一次启动为主。
方案一、打开任务管理器,先关闭守护进程,在关闭主进程
方案二、使用dos命令关闭Nginx
taskkill /f(强制关闭) /im(镜像名称) nginx.exe(服务名称)
Nginx默认会监听80端口,要求80端口不能被占用
1.查看80端口是否被占用
netstat -ano|findstr "80"
2.锁定80端口后,查看对应PID
3.执行dos命令杀进程、或者直接打开任务管理器根据PID结束任务
终止指定进程
taskkill /pid PID
强行杀死进程
taskkill /F /pid PID
启动失败多半是配置文件的语法有误,在执行start nginx命令或者nginx -s reload命令后查看,报错信息、也可以打开nginx日志文件查看报错原因。