第三篇 nginx 作为http服务器及详细配置项下,附8种负载均衡策略

最新推荐文章于 2024-03-30 23:36:22 发布

木秀林

最新推荐文章于 2024-03-30 23:36:22 发布

阅读量497

点赞数

分类专栏： nginx 文章标签： nginx linux

本文链接：https://blog.csdn.net/qq_35530042/article/details/109725889

版权

nginx 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Nginx 专栏目录

1. Server

一个server 表示一个虚拟主机 ,会包含监听端口,服务名, 字符集 , 多个 location 资源,如:

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/host.access.log  main;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }
        error_page   500 502 503 504  /50x.html;#错误页面

}

listen用于指定虚拟主机的服务端口
server_name用来指定IP地址或者域名，多个域名之间用空格分开。
index用于设定访问的默认首页地址，root指令用于指定虚拟主机的网页根目录，这个目录可以是相对路径，也可以是绝对路径。
Charset用于设置网页的默认编码格式。
access_log用来指定此虚拟主机的访问日志存放路径，最后的main用于指定访问日志的输出格式。
error_page 可以设置错误页面，错误页面根据返回的状态码统一返回

建议将对虚拟主机进行配置的内容写进另外一个文件，然后通过include指令包含进来，这样更便于维护和管理。

1.1 location

location 代表每一个URL请求最后落在哪里,给谁处理或者请求哪个文件返回给客户端

location 支持的语法location [=|~|~*|^~|@] pattern { ... }

location 代表关键字,后面跟着匹配模式 = ~ ~* ^~ @ , pattern 代表正则表达式之后就是location体 , 所以主要就是三个:1.匹配模式,2.正则3.属性体

1.1.1 匹配模式 `= ~ ~* ^~ @`

= 修饰符：要求路径完全匹配

server {   

 server_name website.com;    

location = /abcd { 

 
}

}

表示需要完全匹配/abcd,如

http://website.com/abcd匹配
http://website.com/ABCD可能会匹配，也可以不匹配，取决于操作系统的文件系统是否大小写敏感（case-sensitive）。ps: Mac 默认是大小写不敏感的，git 使用会有大坑。
http://website.com/abcd?param1&param2匹配，忽略 querystring
http://website.com/abcd/不匹配，带有结尾的/
http://website.com/abcde不匹配

~ 修饰符：区分大小写的正则匹配

server { 
   server_name website.com;   
 location ~ ^/abcd$ { 
}
}

^/abcd$这个正则表达式表示字符串必须以/开始，d结束，中间必须是abc
http://website.com/abcd匹配（完全匹配）
http://website.com/ABCD不匹配，大小写敏感
http://website.com/abcd?param1&param2匹配
http://website.com/abcd/不匹配，不能匹配正则表达式
http://website.com/abcde不匹配，不能匹配正则表达式

!~ 修饰符：区分大小写的正则不匹配

server { 
   server_name website.com;   
 location !~ ^/abcd$ { 
}
}

^/abcd$这个正则表达式表示字符串必须以/开始，d结束，中间必须是abc ,如果对上了则不走这个location
http://website.com/abcd 不匹配（完全匹配）
http://website.com/ABCD匹配，大小写敏感
http://website.com/abcd?param1&param2 不匹配
http://website.com/abcd/ 匹配，不能匹配正则表达式
http://website.com/abcde匹配，不能匹配正则表达式

相当于对上面的规则取反

~* 不区分大小写的正则匹配

server {   
 server_name website.com;  
  location ~* ^/abcd$ {  
  }
}

http://website.com/abcd匹配(完全匹配)
http://website.com/ABCD匹配(大小写不敏感)
http://website.com/abcd?param1&param2匹配
http://website.com/abcd/不匹配，不能匹配正则表达式
http://website.com/abcde不匹配，不能匹配正则表达式

同样也有个 !~* 对上面的取反

^~ 修饰符：前缀匹配

如果该 location 是最佳的匹配，那么对于匹配这个 location 的字符串，该修饰符不再进行正则表达式检测。

注意，这不是一个正则表达式匹配，它的目的是优先于正则表达式的匹配

@ 修饰符 : nginx内部跳转

location /index/ {
    error_page 404 @index_error;
}

location @index_error {
   .....
}

以 /index/ 开头的请求，如果链接的状态为 404。则会匹配到 @index_error 这条规则上。

默认不加任何修饰符

location /index/ {
    ......
}

# 匹配到所有uri
location / {
    ......
}

不加任何规则则时，默认是大小写敏感，前缀匹配，相当于加了“^”
只有 / 表示匹配所有uri

#http://abc.com/index [匹配成功]
#http://abc.com/index/index.page [匹配成功]
#http://abc.com/test/index [匹配失败]
#http://abc.com/Index [匹配失败]

查找的顺序及优先级

当有多条 location 规则时，nginx 有一套比较复杂的规则，优先级如下：

精确匹配=
前缀匹配^~（立刻停止后续的正则搜索）
按文件中顺序的正则匹配_或*
匹配不带任何修饰的前缀匹配。

1.1.2 正则表达式

正则表达式使用通用正则即可,这里就不描述

1.1.3 location 属性体

一般会有两种用法:

静态代理
动态代理

nginx静态代理

指定文件路径有两种方式root和alias，root与alias主要区别在于nginx如何解释location后面的uri，这会使两者分别以不同的方式将请求映射到服务器文件上

先放个官网链接

alias: http://nginx.org/en/docs/http/ngx_http_core_module.html#alias
root: http://nginx.org/en/docs/http/ngx_http_core_module.html#root

location /i/ {
    alias /data/w3/images/;
}
location /i/ {
    root /data/w3/images/;
}

相同的路径，相同请求 /i/demo.jpg
alias 返回的是/data/w3/images/demo.jpg
root 返回的是/data/w3/images/i/demo.jpg

同时还有几点注意的

使用alias时，目录名后面一定要加"/"，不然会认为是个文件。
alias在使用正则匹配时，location后uri中捕捉到要匹配的内容后，并在指定的alias规则内容处使用。

location ~ ^/users/(.+\.(?:gif|jpe?g|png))$ {
    alias /data/w3/images/$1;
}

alias只能位于location块中，而root的权限不限于location。

index 用于指定默认的首页路径 ,前面server 中也用到过

nginx动态代理

动态代理也可以叫反向代理，主要使用的就是 proxy_pass

proxy_pass 直接在后面接上代理的路径或者serverName(就是后面讲的搭配负载均衡使用)

location /
{
proxy_pass http://127.0.0.1:8008;
}

2.upstream

upstream是Nginx的HTTP Upstream模块，这个模块通过一个简单的调度算法来实现客户端IP到后端服务器的负载均衡。如:

注意:这里不能使用_ 去命名 , 不然代理tomcat 报错

upstream cszhi.com{
ip_hash;
server 192.168.8.11:80;
server 192.168.8.12:80 down;
server 192.168.8.13:8009 max_fails=3 fail_timeout=20s;
server 192.168.8.146:8080 backup;
server 192.168.8.146:8081 weight=2;
}

在上面的设定中，通过upstream指令指定了一个负载均衡器的名称cszhi.com。(这个名称可以任意指定，在后面需要的地方直接调用即可)
同时使用了 ip_hash 的负载均衡策略,配置了四个server:

第一个是最常见的写法
第二个down 表示停机,不加入负载均衡
第三个表示 max_fails=3 失败3次, fail_timeout=20s; 失败时长20秒 ,达到后给他停机,不加入负载均衡
第四个表示备用机,其他的不行了就用这个顶上,平常不使用
第五个表示weight负载的权重，默认为1。weight越大，表示这台服务器被访问的几率就越大。使用这个是表示使用权重策略负载均衡,这里只是示例

还有一个是 fail_time 服务器会被认为停机的时间长度,默认为10s。

2.1 所有策略类型

2.1.1 轮询(默认)

挨个轮过去,一个请求换一个


upstream balanceServer {
    server localhost:8081;
    server localhost:8082;
    server localhost:8083;
    server localhost:8084;
}

2.1.2 随机法

完全随机,点到谁就是谁


upstream server_group { 
   random; 
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

2.1.3 权重法(加权轮询)

在实际使用中可能出现一些机器硬件比较好,那能者多劳权重分高点,多抗些流量了

upstream balanceServer {
    server localhost:8081;
    server localhost:8082 backup;
    server localhost:8083 max_fails=3 fail_timeout=20s;
    server localhost:8084 weight=2;
}

2.1.4 响应的时长(fair)

配置参考：需要在Nginx编译时加入nginx-upstream-fair模块。


upstream server_group{
   fair;
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

2.1.5 最少连接数

这个策略是把请求转发给连接数较少的后端服务器。前面的轮询策略是把请求平均地转发给集群中的每个后台服务器，使得它们的负载大致相同，但是有些请求可能占用的时间会很长，可能导致所在的后端负载过高。这种情况下选用least_conn策略就能达到更好的负载均衡效果。


upstream server_group {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

2.1.6 IP哈希（ip_hash）

根据请求的IP进行hash,让一个用户的所以请求都在同一台机器上,可以解决Session一致问题


upstream balanceServer {
    ip_hash; # 指定负载均衡策略为ip_hash
    server localhost:8081;
    server localhost:8082 backup;
    server localhost:8083 max_fails=3 fail_timeout=20s;
    server localhost:8084 weight=2;
}

2.1.7 请求URI哈希

ngx_http_consistent_hash

根据请求的uri 进行hash,使用url_hash，可以使得同一个url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再此收到请求，就可以从缓存中读取。


upstream server_group{
   hash $request_uri consistent;
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

2.1.8 sticky 策略

该策略是在多台服务器的环境下，确保一个客户端只和一台服务器通讯，它会保持长连接，并在结束会话后再次选择一个服务器，保证了压力均衡,同时也能保证Session一致。

nginx-sticky-module-ng，再对我们的 nginx 进行重新编译安装，nginx-sticky-module-ng 模块在第三方模块网站中能够找到下载


    upstream westos{


        sticky;  #粘滞算法

        server 172.25.28.2:80;

        server 172.25.28.3:80;


        }

木秀林

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录