目录
一、Linux安装nginx
一、Linux部署nginx_傲娇的喵酱的博客-CSDN博客_linux nginx部署
二、 nginx简介
Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx,是一个高性能的HTTP和反向代理服务器。特点是占有的内存少,并发能力强。
nginx 是C语言编写的。nginx的工作模式,是多进程的,而不是多线程的。
童鞋,你思考一下,为啥是多进程模式,而不是多线程模式呢?
正向代理
需要在客户端配置代理服务器进行指定网站访问
如果把局域网外的 Internet 想象成一个巨大的资源库,则局域网中的客户端要访 问 Internet,则需要通过代理服务器来访问,这种代理服务就称为正向代理。
反向代理
暴露的是代理服务器地址,隐藏了真实服务器 IP 地址。
反向代理,其实客户端对代理是无感知的,因为客户端不需要任何配置就可以访问,我们只需要将请求发送到反向代理服务器,由反向代理服务器去选择目标服务器获取数据后,在返回给客户端,此时反向代理服务器和目标服务器对外就是一个服务器,暴露的是代理服务器地址,隐藏了真实服务器 IP 地址。
动静分离
为了加快网站的解析速度,可以把动态页面和静态页面由不同的服务器来解析,加快解析速度。降低原来单个服务器的压力。
这里应该是单独的文件服务器
负载均衡
增加服务器的数量,然后将请求分发到各个服务器上,将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上,将负载分发到不同的服务器,也就是我们所说的负载均衡
原文地址:
Nginx 简介_fFee-ops的博客-CSDN博客_nginx介绍
三、Nginx基本命令
nginx的启动文件,目录:
/usr/local/webserver/nginx/sbin/nginx
查看启动命令说明
[root@iz2ze2w3v37sit3vf71kuez sbin]# ./nginx -?
nginx version: nginx/1.6.2
Usage: nginx [-?hvVtq] [-s signal] [-c filename] [-p prefix] [-g directives]
Options:
-?,-h : this help
-v : show version and exit
-V : show version and configure options then exit
-t : test configuration and exit
-q : suppress non-error messages during configuration testing
-s signal : send signal to a master process: stop, quit, reopen, reload
-p prefix : set prefix path (default: /usr/local/webserver/nginx/)
-c filename : set configuration file (default: conf/nginx.conf)
-g directives : set global directives out of configuration file
-s signal : send signal to a master process: stop, quit, reopen, reload
直接启动./nginx
[root@ecs-39233 sbin]# ./nginx
-s reload
[root@iz2ze2w3v37sit3vf71kuez sbin]# ./nginx -s reload
用户无感知重启,比如修改了nginx配置文件,然后执行reload重启,则在重启成功之前,nginx依然在按照老的配置在工作,重启成功后,按照新的配置工作
-s stop
[root@ecs-39233 sbin]# ./nginx -s stop
立即停止
-s quit
处理完当前请求后,停止
./nginx -s quit
四、Nginx 配置文件详解------支持高并发
nginx配置文件为nginx.conf
文件位置:
/usr/local/webserver/nginx/conf/nginx.conf
4.1 nginx 为多进程模式(tomcat是多线程模式)
worker_processes 1; #工作进程:数量,根据硬件调整,通常等于CPU数量
错误日志位置及级别
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
nginx启动后,会生成一个pid文件,记录 nginx主进程的 ID 号。
#pid logs/nginx.pid;
4.2 worker_rlimit_nofile
worker_rlimit_nofile :
# 指定进程可以打开最大的描述符:数目
整个 nginx 打开文件数的总和,如果不设的话上限就是系统的open files 的值。
nginx同时连接的数量受限于linux系统上可用的文件描述符的数量,linux 一切皆文件。
我们先查看ningx.conf文件里worker_rlimit_nofile里的配置,如果没有的话,就是默认配置,这个值的上限就是系统open files 的值。
在linux 上,查看open files 的值
ulimit -a
查看open files的值,如果这个值是1024的话(linux系统,可同时最大打开1024个文件),改成65535。
修改open files的方法,执行命令:
ulimit -n 65535
然后再配置ningx.conf文件里worker_rlimit_nofile的值,可以配置,如果要配置的话,要等于65535
worker_rlimit_nofile 65525;
也可以不配置,则默认上限就是linux系统的open files 的值。
4.3 events
默认配置
events默认配置,只有worker_connections 1024,我们需要手动配置use epoll。
events {
use epoll; #支持大并发的原因,使用Linux异步I/O模式。(默认使用同步,我们需要手动修改成异步)这里必须使用异步I/O
}
events {
worker_connections 1024;
use epoll;
}
worker_connections:每个工作进程最大的连接数量,根据硬件调整,和前边的工作进程配合起来用。当来大量并发,处理不过来时就会产生排队,允许排队的最大数量。多余这个值的请求就会报502了,这里建议多配置一些,默认是1024.
keepalive_timeout 60; #超时时间
client_header_buffer_size 4k; #客户端请求头部的缓冲区大小。这个可以根据你系统设置分页大小来设置,建议设置成4k或4k的倍数。
open_file_cache max=65535 inactive=60s;
# 这个将为打开文件指定缓存,默认是关闭的。max指定缓存数量,
把header缓存起来,就会走nginx的缓存,静态文件、图片等等,不经过tomcat和后端服务,直接返回资源, (tomcat处理静态资源效率不高,适合处理动态请求)。
inactive=60s 如果60s,没有再次被用到,属于非热点数据,会被缓存里清掉,这几个是配合使用的。
open_file_cache min uses 3;
# open_file_cache 指令中的inactice参数时间内文件的最少使用次数,如果超过这个,属于热点数据。非热点数据会在缓存里清理掉。
这里要配合使用,如
open_file_cache max=65535 inactive=60s; open_file_cache min uses 3;
60s内,被使用3次的属于热点数据,非热点数据会在缓存里清理掉。
open_file_cache_valid 60s;
这个指多长时间检查一下缓存有效的信息,如,这里设置60s,则60s检查一下缓存内数据是否失效,失效的被清理掉。
五、负载均衡配置
Nginx负载均衡的详细配置及使用案例详解. - 一枝花算不算浪漫 - 博客园
Nginx服务器之负载均衡策略(6种) - 左羽 - 博客园
nginx的负载均衡主要是对proxy_pass和upstream的配置。
nginx本身就是一个web容器,既可以作为一个web容器,也可以作为负载均衡使用。负载均衡,需要配置upstream;web容器需要配置server。
负载均衡,upstream不是一个,可以有好多个。如:
upstream foo1 和upstream foo2
负载均衡整个流程:
1)首先配置 upstream upstream_name {} 要映射的服务器。其中的upstream_name大家可以指定为服务的域名或者项目的代号,这个名字是自己取的。
2)在http server下,来执行刚刚配置服务upstream_name的转发。
1)配置upstream (http模块内server模块外添加代码)
upstream bakend {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
}
2)在http server模块location 下配置proxy_pass
如下,是配置完整的
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream bakend {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
}
server {
listen 80;
server_name localhost;
location /status {
root html;
index index.html index.htm;
stub_status on;
access_log on;
}
location / {
proxy_pass http://bakend;
}
重启nginx就生效了。
5.1 nginx负载均衡策略
nginx的负载均衡策略有6种:
轮询 | 默认方式 |
weight | 权重方式 |
ip_hash | 依据ip分配方式 |
least_conn | 最少连接方式 |
fair(第三方) | 响应时间方式 |
url_hash(第三方) | 依据URL分配方式 |
5.1.1 轮询(默认)
最基本的配置方法,它是upstream的默认策略,每个请求会按时间顺序逐一分配到不同的后端服务器。
参数有:
参数 | 描述 |
fail_timeout | 与max_fails结合使用 |
max_fails | 设置在fail_timeout参数设置的时间内最大失败次数,如果在这个时间内,所有针对该服务器的请求都失败了,那么认为该服务器会被认为是停机了 |
fail_time | 服务器会被认为停机的时间长度,默认为10s。 |
backup | 标记该服务器为备用服务器。当主服务器停止时,请求会被发送到它这里。 |
down | 标记服务器永久停机了。 |
注意:
- 在轮询中,如果服务器down掉了,会自动剔除该服务器。
- 缺省配置就是轮询策略。
- 此策略适合服务器配置相当,无状态且短平快的服务使用。
弊端:
轮询策略弊端,不能解决session共享问题。如我访问一个网站,同时会发出多个不同请求,打到不同的服务器上,再把结果返回给客户端。
不同的请求,seeesion不同。
Session共享问题解决方案:
由于请求先通过Nginx代理服务器,再有nginx服务器分配请求到具体的应用服务器中间就会遇到Session共享问题:
1.ip_hash 根据ip分配请求的应用服务器
2.不使用session,换cookie就不会存在此问题,但是网站安全度降低
3.使用cookie和redis缓存(建议此方案,方便扩展,缓存中速度高效)
例如:生成一个uuid作为用户信息的key存放在redis缓存中,再将uuid作为cookie的值写会客户端,cookie的key可以用固定值(常量)
4.放到MySQL数据库中,不推荐(增加数据库的io)
5.自己修改编写nginx的程序
参考链接:
Nginx负载均衡的SESSION共享问题解决方案_锦衣夜行_-CSDN博客_nginx负载均衡session处理
5.1.2 权重
在轮询策略的基础上制定轮询的几率。例如
upstream foo {
server localhost:8001 weight=2;
server localhost:8002;
server localhost:8003 backup;
server localhost:8004 max_fails=3 fail_timeout=20s;
}
这里例子中,weight参数用于制定轮询的几率,weight默认值为1;weight的数值和被访问的几率成正比。
注意:
- 权重越高分配到需要处理的请求越多。
- 此策略可以与least_conn和ip_hash结合使用。
- 此策略比较适合服务器的硬件配置差别比较大的情况。
5.1.3 ip_hash
负载均衡器按照客户端IP地址的分配方式,可以确保相同客户端的请求一直发送到相同的服务器。这样每个访客都固定访问一个后端服务器。
(每个请求按访问ip的hash结果进行分配,这样每个访客固定访问一个后端服务器,可以解决session问题)
upstream foo {
ip_hash;
server localhost:8001
server localhost:8002;
server localhost:8003;
server localhost:8004;
}
注意:
- 在nginx版本1.3.1之前,不能在ip_hash中使用权重(weight)。
- ip_hash不能与backup同时使用。
- 此策略适合有状态服务,比如session。
- 当有服务器需要剔除,必须手动down掉。
5.1.4 least_conn 最小连接
把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端,使它们的负载大致相同;但是,有些请求占用的时间很长,会导致其所在的后端负载较高。这种情况下,least_conn这种方式就可以达到更好的负载均衡效果。
upstream foo {
least_conn;
server localhost:8001 weight=2;
server localhost:8002;
server localhost:8003 backup;
server localhost:8004 max_fails=3 fail_timeout=20s;
}
注意:
- 此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。
除了上面这些调度策略之后,还有一些第三方的调度策略可以集成到nginx中。
在实际运用中,需要根据不同的场景选择不同的策略,大多是多种策略结合使用以达到实际需求的性能
5.1.5 fair(第三方)
按后端服务的响应时间来分配请求,响应时间短的优先分配。
upstream foo {
fair;
server localhost:8001 ;
server localhost:8002;
server localhost:8003 ;
server localhost:8004 ;
}
fair模块需要单独安装
5.1.6 url_hash(第三方)
按访问的url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
例,在upstream 中加入hash语句,server语句中不能写入height等其他参数,hash_method是使用的hash算法。
upstream foo {
server server1:8001 ;
server server2:8001 ;
hash $request_rul;
hash_method crc32;
}
其他的配套参数:
upstream foo { #定义负载均衡设备的ip及设备状态}{
server localhost:8002 down;
server localhost:8001 weight=2;
server localhost:8002;
server localhost:8003 backup;
server localhost:8004 max_fails=3 fail_timeout=20s;
}
--down 表示暂不启用,这个ip现在不参与请求的转发,相当于注释掉了。把down删除掉,就可以重新参与请求转发了。
--backup 备用机器,平时不用,压力不大,不参与负载均衡转发,当压力足够大时,自动参与到负载均衡的转发
--max_fails:允许请求失败的默认次数为1,当超过最大次数时,返回proxy_next_upstream模块定义的错误。
--fail_timeout:max_fails 失败次后,暂停的时间。
--max_fails=3 fail_timeout=20s 这个ip,如果转发失败3次,则暂停该服务的转发,20s之后,继续使用该转发服务
负载均衡的种类
1)一种是通过硬件来进行解决,常见的硬件有NetScaler、F5、Radware和Array等商用的负载均衡器,但是它们是比较昂贵的
2)一种是通过软件来进行解决的,常见的软件有LVS、Nginx、apache等,它们是基于Linux系统并且开源的负载均衡策略。
原文地址:
如何监控Nginx(看完这篇就会了)_咸蛋黄派的博客-CSDN博客_nginx监控
六、监控
web 服务器 nginx 以其高性能与抗并发能力越来越多的被用户使用。Nginx 提供了 ngx_http_stub_status_module
、ngx_http_reqstat_module
模块,这两个模块提供了基本的监控功能。
进程监控
端口监控
注意: 这两个是必须要加在zabbix监控,加触发器有问题及时告警。
6.1 监控的主要指标
即主要监控对象:
1、基本活跃指标
名称 | 描述 | 指标类型 |
---|---|---|
Accepts (接受) | NGINX 所接受的客户端连接数 | 资源: 功能 |
Handled (已处理) | 成功的客户端连接数 | 资源: 功能 |
Dropped (已丢弃,计算得出) | 丢弃的连接数(接受 - 已处理) | 工作:错误* |
Requests (请求数) | 客户端请求数 | 工作:吞吐量 |
2、每秒请求数–QPS
通过持续的 QPS 监控,可以立刻发现是否被恶意攻击或对服务的可用性进行评估。虽然当问题发生时,通过 QPS 不能定位到确切问题的位置,但是他却可以在第一时间提醒你环境可能出问题了。
3、服务器错误率
通过监控固定时间间隔内的错误代码(4XX代码表示客户端错误,5XX代码表示服务器端错误),可以了解到客户端收到的结果是否是正确的错误率突然的飙升很可能是你的网站漏洞发出的信号。
如果你希望通过 access log 分析错误率,那么你需要配置 nginx 的日志模块,让 nginx 将响应码写入访问日志。
6.2 指标收集
1、Nginx stub 模块监控
(1)模块安装
确保Linux上已安装配置好Nginx,一定要有--with-http_stub_status_module这个模块,可以在Nginx的sbin目录下输入./nginx -V进行查看,如果没有可以在编译时加上此模块。
./configure –with-http_stub_status_module
默认情况下,status是关闭的,我们需要开启,并指定uri来访问数据。通过配置,在nginx配置文件中的server块中增加
server {
listen 80;
server_name localhost;
location /status {
stub_status on;
access_log on;
}
}
/status 配置的是监控的路径,将来访问这个http://124.70.87.136/status
地址,就可以查看监控页面(/status 也可以不配置,访ip:80就可以查看到监控)
stub_status on 开启监控
access_log on 开启日志
我的nginx.conf 配置文件路径。
/usr/local/webserver/nginx/conf/nginx.conf
配置nginx.conf完成后,
先关掉nginx
/usr/local/webserver/nginx/sbin/nginx -s stop
再启动nginx
/usr/local/webserver/nginx/sbin/nginx
这里不能使用这个重启命令,
/usr/local/webserver/nginx/sbin/nginx -s reopen
使用reopen,我发现配置没有生效。
# 重新载入配置文件,使用reload应该也是可以的
/usr/local/webserver/nginx/sbin/nginx -s reload
启动nginx成功后,访问:
Active connections:与后端建立的服务连接数
server accepts handled requests:Nginx总共处理了17个连接,成功创建了17次握手,总共处理了36个请求
Reading:nginx读取到客户端的Header信息数
Writing:nginx返回到客户端的Header信息数
Waiting:开启Keep-alive的情况下,这个值等于 Active -(Reading + Writing)。表示nginx已经处理完成,正在等候下次一次请求的连接数。
这里详细讲解一下server accepts handled requests:
17 17 36
36是处理的请求数量,注意这里是请求数量。我们用同一个浏览器访问
http://124.70.87.136/nginx-status
观察处理请求数量的变化。连续刷新几次页面,发现
随着每次刷新页面,处理的总请求数量会+1,但是 总共处理的连接数量、创建的握手数量是不发生变化的。
Nginx总共处理了17个连接,成功创建了17次握手,总共处理了36个请求。
我们使用jmeter 给 http://124.70.87.136:80 , 10个并发,循环次数是永远。
再查看监控。当前有11个活跃连接
(3)Stub Status 参数说明(是否有请求排队情况)
Reading:nginx读取到客户端的Header信息数
Writing:nginx返回到客户端的Header信息数
Waiting:开启Keep-alive的情况下,这个值等于 Active -(Reading + Writing)。表示nginx已经处理完成,正在等候下次一次请求的连接数。
reading 指的是nginx 接收的请求数量
writing指的是nginx处理请求的数量
waiting 表示nginx已经处理完成,正在等候下次一次请求的连接数。这个指的不是请求排队的数量。
正常情况下waiting数量是比较多的,并不能说明性能差。
如果reading+writing数量比较多,大于我们设置的ngingx的最大进程连接数量,则说明请求有排队的情况,说明服务并发有问题。
6.3 Nginx Plus
Nginx Plus 相当于付费版本的 Nginx。
提供了更多的功能,针对企业需要的一些服务进行了优化。
nginx plus提供了性能监控等比较全的功能。(nginx plus 有破jie版本)