Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器,同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点(俄文:Рамблер)开发的,第一个公开版本0.1.0发布于2004年10月4日。
本博文不讲解Nginx的安装(官网和其他渠道的讲解都非常多,安装也较为简单),本文重点讲解Nginx使用配置各参数说明、负载均衡各场景配置说明。
文件根目录
----events:指令是设定Nginx的工作模式及连接数上限
----http:
----upstream:负载均衡服务器设置,设置一系列的后端服务器
----server:主机设置
----server:主机设置
----location:URL匹配特定位置的设置
----location:URL匹配特定位置的设置
#(默认不配置)指定Nginx Worker进程运行用户以及用户组,默认由nobody账号运行。
user nobody nobody;
#Nginx要开启的进程数。每个Nginx进程平均耗费10M~12M内存。建议指定和CPU的数量一致即可。
worker_processes 2;
#(默认不配置)指定全局错误日志文件。级别有debug、info、notice、warn、error、crit可供选择. debug级别最为最详细,crit输出日志最少。
error_log logs/error.log notice;
#(默认不配置)用来指定进程pid的存储文件位置。
pid logs/nginx.pid;
#(默认不配置)用于绑定worker进程和CPU, Linux内核2.4以上可用。
worker_rlimit_nofile 65535;
#指令是设定Nginx的工作模式及连接数上限
events{
#(默认不配置)指定Nginx的工作模式:select、poll、kqueue、epoll、rtsig和/dev/poll。
#其中select和poll都是标准的工作模式,kqueue和epoll是高效的工作模式. epoll用在Linux平台上,kqueue用在BSD系统中。
use epoll;
#指定Nginx每个进程的最大连接数(默认是1024). 最大客户端连接数由worker_processes和worker_connections决定,Max_client=worker_processes*worker_connections。
#在作为反向代理时,max_clients变为:Max_client = worker_processes * worker_connections/4。
#进程的最大连接数受Linux系统进程的最大打开文件数限制,在执行操作系统命令"ulimit -n 65536"后worker_connections的设置才能生效
worker_connections 65536;
}
#服务器相关配置
http {
...
}
http {
#实现对配置文件所包含的文件的设定,可以减少主配置文件的复杂度。默认不变
include mime.types;
#设定默认类型为二进制流,也就是当文件类型未定义时使用这种方式。默认不变
default_type application/octet-stream;
#(默认不配置)指定Nginx日志的输出格式。main为此日志输出格式的名称,可以在下面的access_log指令中引用。
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
#(默认不配置)设置允许客户端请求内容最大字节数
client_max_body_size 20m;
#(默认不配置)设置客户端请求头的headerbuffer大小。一般1K的缓冲区大小已经足够;
client_header_buffer_size 8K;
#用于开启高效文件传输模式。将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
#设置客户端连接保持活动的超时时间(单位为秒)。设置过大会导致问题(socket() failed (24: Too many open files) while connecting to upstream),设置过小会导致大文件上传超时。
keepalive_timeout 60;
#(默认不配置)设置请求头读取超时时间。如果超过这个时间,客户端还没有发送任何数据,Nginx将返回“Request time out(408)”错误;
client_header_timeout 10;
#(默认不配置)设置客户端请求主体读取超时时间。如果超过这个时间,客户端还没有发送任何数据,Nginx将返回“Request time out(408)”错误,默认值是60;
client_body_timeout 10;
#(默认不配置)指定响应客户端的超时时间。这个超时仅限于两个连接活动之间的时间,如果超过这个时间,客户端没有任何活动,Nginx将会关闭连接。
send_timeout 20;
#设置开启或者关闭gzip模块,“gzip on”表示开启GZIP压缩,实时压缩输出数据流
gzip on;
#设置允许压缩的页面最小字节(header中Content-Length可以获取大小)。默认值0代表都压缩(不能这么用,可能导致小文件压缩反而大的情况)。建议设置成大于1K的字节数;
gzip_min_length 1k;
#表示申请4个单位为16K的内存作为压缩结果流缓存,默认值是申请与原始数据大小相同的内存空间来存储gzip压缩结果;
gzip_buffers 4 16k;
#用来指定GZIP压缩比,1 压缩比最小,处理速度最快;9 压缩比最大,传输速度快,但处理最慢,也比较消耗cpu资源;
gzip_comp_level 5;
#用来指定压缩的类型,无论是否指定,“text/html”类型总是会被压缩的;
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
#选项可以让前端的缓存服务器缓存经过GZIP压缩的页面,例如用Squid缓存经过Nginx压缩的数据。
gzip_vary off;
#IE6对Gzip不怎么友好,不给它Gzip了
gzip_disable "MSIE [1-6]\.";
#负载均衡设置,负载名称将会被location中的proxy_pass引用(最后章节详细介绍)
upstream 负载名称{
负载配置内容
}
#server虚拟主机配置(建议将一个虚拟主机server的配置写成一个独立文件,通过include指令包含进来,这样更便于维护和管理)
server{
...
}
}
#server虚拟主机配置(建议将一个虚拟主机server的配置写成一个独立文件,通过include指令包含进来,这样更便于维护和管理)
server{
#指定服务端口
listen 80;
#IP地址或者域名,多个域名之间用空格分开,指明服务地址
server_name 192.168.8.18 cszhi.com;
#设定访问的默认首页地址
index index.html index.htm index.php;
#指定虚拟主机的网页根目录,这个目录可以是相对路径,也可以是绝对路径
root /wwwroot/www.cszhi.com
#(默认不配)设置网页的默认编码格式
charset gb2312;
#(默认不配)此虚拟主机的访问日志存放路径,最后的main用于指定访问日志的输出格式(引用前面的设置)。
access_log logs/www.tasktrack.com.cn main;
#location代表URL满足规律的进入本区域处理(下面示例代表 匹配aiassistant开头的URL地址)
location ~ .*/aiassistant/* {
#基本语法如下:location [=|~|~*|^~|@] pattern{……} 详细语法说明如下
#没有修饰符 表示:必须以指定模式开始; location /abc 代表 /abc、/abc?p1、/abc/、/abcde都可以匹配
#=表示必须与指定的模式精确匹配; location = /abc 代表 /abc、/abc?p1可以匹配;/abc/、/abcde不可以匹配
#~表示指定的正则表达式要区分大小写; location ~ ^/abc$ 代表 /abc、/abc?p1=1可以匹配;/ABC、/abc/、/abcde不可以匹配
#~*表示指定的正则表达式不区分大小写; location ~* ^/abc$代表/abc、/ABC、/abc?p=1可以;/abc/、/abcde不可以匹配
#^~类似于无修饰符的行为,也是以指定模式开始,不同的是,如果模式匹配,那么就停止搜索其他模式了。
#@:定义命名location区段,这些区段客户段不能访问,只可以由内部产生的请求来访问,如try_files或error_page等
#location各模块优先级:
#1:带有"="的精确匹配优先
#2:没有修饰符的精确匹配
#3:正则表达式按照他们在配置文件中定义的顺序
#4:带有"^~"修饰符的,开头匹配
#5:带有"~" 或"~*" 修饰符的,如果正则表达式与URI匹配
#6:没有修饰符的,如果指定字符串与URI开头匹配
#示例: location = / 代表:只匹配 / 的查询
#示例: location / 代表:匹配任何以 /开始的查询,但是正则表达式与一些较长的字符串将被首先匹配。
#示例: location ^~ /images/ 代表:匹配任何以 /images/开始的查询并且停止搜索,不检查正则表达式。
#示例: location ~* \.(gif|jpg|jpeg)$ 代表:匹配任何以gif、jpg、jpeg结尾的文件,但是所有/images/目录的请求将在上一个示例中匹配
#符合location条件的请求路径被转发URL地址,可以使用负载upstream设置的名称(注意最后有/根路径和没有/相对路径的区别)
proxy_pass http://127.0.0.1:8100; 待补充
#重新设置代理转发的请求头Host(请求的主机名)为真实客户端请求Host,并且防止Host为空的情况(否则后端服务器收到的Host永远是nginx的host)
proxy_set_header Host $host;
#重新设置代理转发的请求头IP地址为最原始客户端请求IP地址
proxy_set_header X-Real-IP $remote_addr;
#重新设置代理转发的请求头IP地址为最原始客户端请求IP地址
proxy_set_header REMOTE-HOST $remote_addr;
#重新设置代理转发的请求头X-Forwarded-For的值为"用户的真实ip,第一台nginx的ip"(如果只有一集Nginx代理,效果与proxy_set_header X-Forwarded-For $remote_addr 一致)
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#重新设置代理转发的请求头,保持原请求中的协议。 解决https请求,经过nginx转发后,Tomcat只能获得http协议的问题
proxy_set_header X-Forwarded-Proto $scheme;
}
}
upstream 负载设置名称{
负载配置内容
}
负载均衡算法说明如下(配置有单独章节讲解)
负载均衡配置关键字说明(配置有单独章节讲解)
upstream负载均衡配置示例说明
#主备负载策略:在http节点下添加upstream节点:主不可用,切到备,当主服务器再次可用,流量会再次自动切到主服务器上面来。
upstream robotweb {
server 192.168.0.1:8080 max_fails=60 fail_timeout=60s; //主服务器配置,连续60次失败或者60S超时,切到备服务器
server 192.168.0.2:8080 backup; //备服务器地址配置
}
#然后在server节点下配置location内容进行引用:
location /name {
proxy_pass http://robotweb/name/; //这里引用上面配置的upstream的 robotweb名称的负载策略。
}
#多机负载策略:源地址哈希法,适用于希望session保持的业务场景
upstream searchapi {
ip_hash;
server 192.168.0.1:8080;
server 192.168.0.2:8080;
}
#多机负载策略:加权轮询(适用于服务器无状态,并且服务器硬件配置不均衡的场景)
upstream searchapi{
server 11.22.333.11:6666 weight=1; //权重为1的轮训到此节点(值越大负载的量越大)
server 11.22.333.22:8888 down; //表示单前的server临时不參与负载
server 11.22.333.33:8888 backup; //其他全部的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻
server 11.22.333.44:5555 weight=2; //权重为2的轮训到此节点(值越大负载的量越大)
}
#多机负载策略:fair法(非官方):按照服务器响应时间的长短来进行分发的,服务器响应时间越短的,优先分发
upstream searchapi{
server 11.22.333.11:6666 ;
server 11.22.333.22:8888 ;
fair;
}
#多机负载策略:一致性哈希(Consistent Hash),适用于后端是缓存服务器的场景,共3台缓存服务器,其中一台挂了,以前落在另外两台服务器的请求不变.
upstream searchapi{
consistent_hash $request_uri;
server 106.38.193.183:80;
server 106.38.193.182:80;
}
#多机负载策略:根据请求参数做一致性哈希(Consistent Hash),通过lua脚本获得请求参数,并请求组装成nginx使用的hash源
upstream searchapi{
server 10.44.55.67:8080;
server 10.44.55.68:8080;
server 10.44.55.69:8080;
consistent_hash $req_param;
}
location ~.*/searchweb/search/*{
rewirte_by_lua '
local request_method = ngx.var.request_method
if "GET" == request_mothod then
local args = ngx.req.get_rul_args()
ngx.var.req_param = args["client"]
end
';
proxy_pass .....
}