Nginx基础
编辑什么是Nginx
- Nginx(engine x) 是一个高性能的http和反向代理web服务器,同时也提供IMAP/POP3/SMTP服务,
- 通过配置文件可以实现集群和负载均衡
- 静态资源虚拟化
常见的服务器
服务器 | 主要应用 |
---|---|
Weblogic,Jboss | 传统行业,ERP物流 |
Tomcat,Jetty | J2EE |
Apache,Nginx | 静态服务,反向代理 |
MS IIS | asp.net |
Netty | 高性能服务器编程 |
什么是反向代理
正向代理:客户端请求目标服务器之间的一个代理服务器,请求会经过代理服务器,然后再转发请求到目标服务器,获得内容后响应给客户端
反向代理:用户请求目标服务器,由代理服务器决定访问那个IP
Nginx 显示默认首页解析
下面是一段nginx.conf
主配置文件,
- listen代表监听的端口
- server_name 代表监听的服务地址(域名或者ip),内网localhost即可
- location代表文件映射关系,
/
指向Nginx安装目录下的html目录, - index代表索引页,如果目录下有此页面则默认打开
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
nginx.conf
配置结构
main: 全局配置
event: 配置工作模式以及连接数
http: http模块相关配置
server: 虚拟主机配置可以有多个
location: 路由规则表达式
upstream: 集群,内网服务器
Nginx进程模型
默认情况下,Nginx启动只有一个master
进程和一个worker
进程,nginx.conf
配置文件下可以修改worker_process
增加工作线程数;
master进程监听worker,当worker进程异常退出,master会重新启动新的worker进程
信号: 当主进程收到用户发送的信号,会传递给工作进程进行执行
./nginx -s stop
./nginx -s quit
./nginx -s reload
./nginx -t
多worker进程环境下,worker之间相互独立互不影响,各自处理自己的连接或任务,一个worker进程异常不会影响到其他进程,如果用户发出停止Nginx服务的信号,worker进程会等到当前的连接处理完成再退出
Nginx处理Web请求机制解析
worker抢占机制: 通过互斥锁(accept_mutex),worker争抢锁,哪个worker进程获取到锁,则进行一系列数据处理响应的逻辑
传统服务器事件处理: worker进程处理过程处于阻塞状态,当有客户端连接进来,交给空闲的worker进程处理,如果所有的worker进程都处于阻塞状态,则fork一个新的worker进程进行处理;worker进程处理数据时处于同步阻塞状态效率比较低,当并发量过大的时候,会开很多的worker进程,从而加大服务器压力
Nginx事件处理机制:
- 在Linux下使用epoll模型,其他操作系统需要进行修改,一个worker进程可以处理6w-8w个客户端请求,直接和CPU相关,CPU核心数越多,处理的连接数越多,直接提升硬件就可以提高处理能力;
- worker是异步的非阻塞的数据模型,在有限的worker进程数下可以处理几十万甚至上百万的连接,当worker获得客户端连接的时候,处理到阻塞的部分,worker不会等待阻塞的请求,而是同时去处理其他client的请求,从而以较少的开销实现了高并发
- worker可以限制最大的连接数(默认1024),但是不能设置太高否则CPU处于满负荷运行,也不能设置太少,用户请求多,但是连接数比较低的情况,用户请求可能卡顿,需要根据CPU的处理能力设置
nginx.conf
配置文件中events节点下如下配置设置worker进程的最大连接数
events{
# 不设置也是可以的,Linux下默认epoll
use epoll ;
# 每个worker进程允许连接的最大客户端数量
worker_connections 1024;
}
为什么Nginx能做到高性能高并发?
- worker抢占机制
- epoll模型,异步的非阻塞的通知模式(多路复用器)
nginx.pid打开失败以及失效的解决方案
[error] open() /var/run/nginx/nginx.pid failed ...
:文件夹不存在,直接创建文件夹然后赋予相应的权限即可[error] invalid PID number "" in "/var/run/nginx/nginx.pid"
:需要重新设置一下配置文件,默认conf/nginx.conf
,
./nginx -c /usr/local/nginx/conf/nginx.conf
然后再reload即可,另外,log/nginx.pid
目录下也有默认的nginx.pid
./nginx -h
查看帮助文档
Nginx常用命令解析
./nginx -s stop
暴力关闭,正在处理的请求直接关闭,不太友好./nginx -s quit
优雅停止Nginx,当前没有用户请求,直接关闭,若是有用户连接,则维护连接直到连接处理完成关闭才去关闭Nginx,注意:只对http请求才能优雅停止,其他请求不行./nginx -t
检测配置文件的语法是否正确,并且给出提示./nginx -v
显示Nginx版本./nginx -V
显示版本,编译环境版本信息,配置环境等详细信息./nginx -h
或者./nginx -?
查看帮助信息
Nginx日志切割-手动
现有的日志都会存在 access.log 文件中,但是随着时间的推移,这个文件的内容会越来越多,体积会越来越大,不便于运维人员查看,所以我们可以通过把这个大的日志文件切割为多份不同的小文件作为日志,切割规则可以以天为单位,如果每天有几百G或者几个T的日志的话,则可以按需以每半天或者每小时对日志切割一下
- 创建一个shell可执行文件:
cut_my_log.sh
,内容为:
#!/bin/bash
# 这里是日志文件路径
LOG_PATH="/var/log/nginx/"
RECORD_TIME=$(date -d "yesterday" +%Y-%m-%d+%H:%M)
PID=/var/run/nginx/nginx.pid
mv ${LOG_PATH}/access.log ${LOG_PATH}/access.${RECORD_TIME}.log
mv ${LOG_PATH}/error.log ${LOG_PATH}/error.${RECORD_TIME}.log
#向Nginx主进程发送信号,用于重新打开日志文件
kill -USR1 `cat $PID`
- 为cut_my_log.sh添加可执行的权限:
chmod +x cut_my_log.sh
- 测试日志切割后的结果:
./cut_my_log.sh
Nginx日志切割-定时
使用Linux系统的定时任务实现日志切割
-
安装定时任务:
yum install crontabs
-
crontab -e
编辑并且添加一行新的任务:*/1 * * * * /usr/local/nginx/sbin/cut_my_log.sh
-
重启定时任务:
service crond restart
这里需要注意当前用户的权限,加上
sudo crontab -e
在实际操作过程当中发现普通用户添加的定时任务可能因为权限问题无法正常执行,可以关注/var/spool/mail/${username}
文件来查看定时任务执行的日志,定时任务编辑的文件在/var/spool/cron
路径下,以编辑定时任务的用户名称命名
附:常用定时任务命令:
service crond start //启动服务
service crond stop //关闭服务
service crond restart //重启服务
service crond reload //重新载入配置
crontab -e // 编辑任务
crontab -l // 查看任务列表
kill -HUB [nginx主进程号,也就是查看进程命令查到的pid]
//平滑重启
定时任务表达式
Cron表达式是,分为5或者6个域,每个域代表一个含义,如下表所示
分 | 时 | 日 | 月 | 星期几 | 年(可选) | |
---|---|---|---|---|---|---|
取值范围 | 0-59 | 0-23 | 1-31 | 1-12 | 1-7 | 2019/2020/2021... |
常用表达式
每分钟执行
*/1 * * * *
每日凌晨(每天晚上23:59)执行:
59 23 * * *
每日凌晨1点执行:
0 1 * * *
其他应用实例:定时备份数据库https://www.cnblogs.com/leechenxiang/p/7110382.html
使用Nginx为静态资源提供服务
首先在nginx.conf
主配置文件中,http内部块加入include vhost/*.conf;
导入主配置文件同级vhost目录里面以.conf
结尾的全部配置文件,然后编写独立的服务配置文件
server{
listen 90 ;
server_name localhost;
# 配置静态网站路径
location / {
root /home/foodie-shop;
index index.html index.htm;
}
# 配置静态文件访问路径,视频音频图片等
# 实际访问路径为localhost:90/resources 实际指向 /home/resources文件夹
location /resources {
root /home;
}
# 别名配置方式,可以隐藏实际的路径
# 访问路径为localhost:90/static 指向/home/resources目录
location /static {
alias /home/resources;
}
}
静态资源配置小结:
- location代表访问路由,不可以重复
- root 路径完全匹配访问,是资源实际所在目录,如果没有设置别名,那么路由地址会追加在路径后
- 推荐使用alias 可以为你的路径做一个别名,对用户透明可以向用户隐藏资源的映射信息
使用Gzip压缩提升请求效率
# 开启gzip压缩功能,提高传输效率,节约宽带
gzip on;
# 限制最小压缩,小于1字节文件不会压缩
gzip_min_length 1;
# 定义压缩的级别(压缩比,文件越大,压缩越多,但是cpu使用会越多)
gzip_comp_level 3;
# 定义压缩文件的类型
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-http-php image/jpeg image/gif image/png application/json
location 的匹配规则解析
空格
:默认匹配,普通匹配
location / {
root /home;
}
=
:精确匹配
location = /resources/img/face1.png {
root /home;
}
~*
:匹配正则表达式,不区分大小写,注意这里匹配的是访问路径,当资源存在则可以访问
#符合条件的图片的显示,图片1.gif依然也会被匹配
location ~* .(GIF|jpg|png|jpeg) {
root /home;
}
~
:匹配正则表达式,区分大小写
# GIF必须大写才能匹配到
location ~ .(GIF|jpg|png|jpeg) {
root /home;
}
^~
:以某个字符路径开头
# 只能访问/resources/img 路径下的资源
location ^~ /resources/img {
root /home;
}
DNS 域名解析
大致流程:浏览器访问DNS(Domain Name System)解析出实际IP地址对应的服务响应给客户端
注意:可以修改
/etc/hosts
文件修改虚拟的主机映射
或者使用SwitchHosts
工具快速切换host
SwitchHosts下载地址
如此配置即可灵活切换虚拟域名
- 0
- 0
-
分享