3-nginx的几种配置实例学习--反向代理、负载均衡、动静分离

反向代理

反向代理一


转发localhost的8080端口

反向代理二

根据不同的端口和路径实现不同服务的转发

准备两个tomcat服务 修改其中一个端口围为8081
分别在两个不同的tomcat的webapp中新建 edu/test.html 和 vod/test.html
在nginx中新增服务配置监听9001端口并根据路径匹配转发服务,重载nginx配置然后再浏览器中访问不同的地址查看结果

location匹配顺序

"="前缀指令匹配,如果匹配成功,则停止其他匹配
普通字符串指令匹配,顺序是从长到短,匹配成功的location如果使用^~,则停止其他匹配(正则匹配)
正则表达式指令匹配,按照配置文件里的顺序,成功就停止其他匹配 如果第三步中有匹配成功,则使用该结果,否则使用第二步结果
注意点
匹配的顺序是先匹配普通字符串,然后再匹配正则表达式。另外普通字符串匹配顺序是根据配置中字符长度从长到短,也就是说使用普通字符串配置的location顺序是无关紧要的,反正最后nginx会根据配置的长短来进行匹配,但是需要注意的是正则表达式按照配置文件里的顺序测试。找到第一个比配的正则表达式将停止搜索。
一般情况下,匹配成功了普通字符串location后还会进行正则表达式location匹配。有两种方法改变这种行为,其一就是使用“=”前缀,这时执行的是严格匹配,并且匹配成功后立即停止其他匹配,同时处理这个请求;另外一种就是使用“^~”前缀,如果把这个前缀用于一个常规字符串那么告诉nginx 如果路径匹配那么不测试正则表达式。
匹配模式及顺序
location = /uri    =开头表示精确匹配,只有完全匹配上才能生效。
location ^~ /uri   ^~ 开头对URL路径进行前缀匹配,并且在正则之前。
location ~ pattern  ~开头表示区分大小写的正则匹配。
location ~* pattern  ~*开头表示不区分大小写的正则匹配。
location /uri     不带任何修饰符,也表示前缀匹配,但是在正则匹配之后。
location /      通用匹配,任何未匹配到其它location的请求都会匹配到,相当于switch中的default。

实验案例

测试"^"和"",nginx配置如下。浏览器输入http://localhost/helloworld/test,返回601。如将#1注释,#2打开,浏览器输入http://localhost/helloworld/test,返回603。注:#1和#2不能同时打开,如同时打开,启动nginx会报nginx: [emerg] duplicate location "/helloworld"...,因为这两个都是普通字符串。

location ^~ /helloworld {      #1
    return 601;
}
        
#location /helloworld {        #2
#    return 602;
#}

location ~ /helloworld {
    return 603;
}

测试普通字符串的长短(普通字符串的匹配与顺序无关,与长短有关)。浏览器输入http://localhost/helloworld/test/a.html,返回601。浏览器输入http://localhost/helloworld/a.html,返回602。

location /helloworld/test/ {        #1
    return 601;
}
        
location /helloworld/ {                #2
    return 602;
}

测试正则表达式的顺序(正则匹配与顺序相关)。浏览器输入http://localhost/helloworld/test/a.html,返回602;将#2和#3调换顺序,浏览器输入http://localhost/helloworld/test/a.html,返回603

location /helloworld/test/ {        #1
    return 601;
}

location ~ /helloworld {            #2
    return 602;
}
        
location ~ /helloworld/test {        #3
    return 603;
}

负载均衡

1、增加upstream 服务池
2、配置转发

Nginx 负载均衡分配策略

nginx 的 upstream 目前支持 4 种方式的分配
1)、轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器 down 掉,能自动剔除。

2)、weight 指定轮询几率,weight 和访问比率成正比,用于后端服务器性能不均的情况。

3)、ip_hash 每个请求按访问 ip 的 hash 结果分配,这样每个访客固定访问一个后端服务器,可以解决 session 的问题。

4)、fair(第三方) 按后端服务器的响应时间来分配请求,响应时间短的优先分配。

5)、url_hash(第三方)

动静分离

通过location指定不同的后缀名实现不同的请求转发。通过expires参数设置,可以设置浏览器缓存过期时间,减少与服务器之前的请求和流量。
具体Expires定义: 是给一个资源设定一个过期时间,也就是说无需去服务端验证,直接通过浏览器自身确认是否过期即可,所以不会产生额外的流量。此种方法非常适合不经常变动的资源。(如果经常更新的文件,不建议使用Expires来缓存),如果设置3d, 表示在这3天之内访问这个URL, 发送一个请求,比对服务器该文件最后更新时间没有变化,则不会从服务器抓取,返回状态码304,如果有修改,则直接从服务器重新下载,返回状态码200。

2、准备工作
(1) 在liunx系统中准备静态资源,用于进行访问
/data/image 图片文件夹
/data/www html文件夹
3、具体配置
(1) 在nginx配置文件中进行配置

Nginx默认是不允许列出整个目录的。如需此功能,打开nginx.conf文件,在location server 或 http段中加入
autoindex on;
另外两个参数最好也加上去:

autoindex_exact_size off;
默认为on,显示出文件的确切大小,单位是bytes。
改为off后,显示出文件的大概大小,单位是kB或者MB或者GB
autoindex_localtime on;
默认为off,显示的文件时间为GMT时间。
改为on后,显示的文件时间为文件的服务器时间

nginx错误码原因以及解决方案:

1、400 bad request错误的原因和解决办法 配置nginx.conf相关设置如下.

client_header_buffer_size 16k;

large_client_header_buffers 4 64k;

根据具体情况调整,一般适当调整值就可以。

2、Nginx 502 Bad Gateway错误

proxy_next_upstream error timeout invalid_header http_500 http_503;

或者尝试设置:

large_client_header_buffers 4 32k;

3、Nginx出现的413 Request Entity Too Large错误

这个错误一般在上传文件的时候会出现,

编辑Nginx主配置文件Nginx.conf,找到http{}段,添加

client_max_body_size 10m; //设置多大根据自己的需求作调整.

如果运行php的话这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误。

post_max_size = 10M

upload_max_filesize = 2M

4、解决504 Gateway Time-out(nginx)

遇到这个问题是在升级discuz论坛的时候遇到的

一般看来, 这种情况可能是由于nginx默认的fastcgi进程响应的缓冲区太小造成的, 这将导致fastcgi进程被挂起, 如果你的fastcgi服务对这个挂起处理的不好, 那么最后就极有可能导致504 Gateway Time-out

现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K。

默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点

在nginx.conf里, 加入: fastcgi_buffers 8 128k

这表示设置fastcgi缓冲区为8×128k

当然如果您在进行某一项即时的操作, 可能需要nginx的超时参数调大点,例如设置成60秒:send_timeout 60;

只是调整了这两个参数, 结果就是没有再显示那个超时, 可以说效果不错, 但是也可能是由于其他的原因, 目前关于nginx的资料不是很多, 很多事情都需要长期的经验累计才有结果.

posted @ 2021-04-10 11:22  雪漠阳光  阅读(107)  评论(0编辑  收藏  举报