网站建设为什么要推广,郑州百度推广seo,怎么修改网站网页的背景图片,广西展厅设计公司Nginx学习#xff1a;upstream服务器组模块 最后一个重点模块内容啦#xff0c;感谢坚持到现在的你和我。总算是向大佬的道路上又前进了一步了。今天的内容主要是服务器组的配置#xff0c;其实更直白点#xff0c;就是 Nginx 负载均衡的配置模块。会不会有小伙伴不明白负载… Nginx学习upstream服务器组模块 最后一个重点模块内容啦感谢坚持到现在的你和我。总算是向大佬的道路上又前进了一步了。今天的内容主要是服务器组的配置其实更直白点就是 Nginx 负载均衡的配置模块。会不会有小伙伴不明白负载均衡是啥如果是新同学还不明白的话要自己查查资料补习一下了哦。 Nginx 的 HTTP 代理是七层代理对应的它的负载均衡也是做的七层负载。现在我们也可以使用后面要学习的 Stream 模块做四层负载不过这个嘛日常开发用不到要用到的话其实还有更好的解决方案毕竟 Nginx 的四层负载还是比较新的而且它的主营业务也不在四层上。 服务器组模块的全名是 ngx_http_upstream_module 模块它可以用于定义可由 proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass 和 grpc_pass 指令引用的服务器组。 我们先来配置一下。 upstream up1 {server 127.0.0.1;server 127.0.0.1:8098;server 192.168.56.89;
}server{listen 8039;access_log logs/39.log upstream;location / {proxy_pass http://up1;}
}server{listen 8098;root /home/www/html1/;
} 在 upstream 中我们先指定了服务器组的名称是 up1 然后通过内部的 server 指令指定了三个服务器可以是 IP 也可以是别名也可以是外网 URL 端口号不加就是 80 。在测试环境中我指定的是本机的 80、8098 两个端口做为两台服务器为了区别8098 端口的 root 目录指向了另外一个目录这个目录我们先前用过它的 index.html 显示的内容和 80 指定的 /usr/local/nginx/html/ 目录下的 index.html 是不同的。另外还有一个是内网的 192.168.56.89 这台虚拟机之前我们也用过了。 然后让 8039 的服务器配置直接反向代理到 up1 这个服务器组。 最简单的一个负载均衡就配置完成了试试吧直接访问首页是不是首页在来回不断切换呀。在默认情况下服务器组的负载均衡走的是轮询的策略也就是一个一个来。如果其中一台服务器出现问题了则由下一台接手直到最后一台返回结果不管结果是 200 还是报错都以最后一台的为准。 是不是很简单那么我们就来继续深入地看一下服务器组相关的变量以及配置信息这回我们先看变量再看配置指令。因为在学习配置指令时有些测试可以通过变量日志看到效果。 今天所有的配置指令都只能在 upstream 模块下配置而 upstream 模块本身只能在 http 模块下进行配置。 变量 服务器组模块提供的变量包括 $upstream_addr 保留 IP 地址和端口或上游服务器的 UNIX 域套接字的路径。如果在请求处理期间联系了多个服务器则它们的地址用逗号分隔例如“192.168.1.1:80,192.168.1.2:80,unix:/tmp/sock”。如果发生从一个服务器组到另一个服务器组的内部重定向由“X-Accel-Redirect”或 error_page 发起则来自不同组的服务器地址用逗号分隔例如“192.168.1.1:80,192.168.1.2:80,unix:/tmp/sock:192.168.10.1:80,192.168.10.2:80”。如果无法选择服务器则该变量将保留服务器组的名称。$upstream_bytes_received 从上游服务器1.11.4接收的字节数。来自多个连接的值由逗号和冒号分隔例如 $upstream_addr 变量中的地址。$upstream_bytes_sent 发送到上游服务器 (1.15.8) 的字节数。来自多个连接的值由逗号和冒号分隔例如 $upstream_addr 变量中的地址。$upstream_cache_status 保持访问响应缓存的状态0.8.3。状态可以是“MISS”、“BYPASS”、“EXPIRED”、“STALE”、“UPDATING”、“REVALIDATED”或“HIT”。$upstream_connect_time 保持与上游服务器建立连接的时间1.9.1时间以毫秒为单位保存。在 SSL 的情况下包括花在握手上的时间。几个连接的时间由逗号和冒号分隔如 $upstream_addr 变量中的地址。$upstream_cookie_[name] 上游服务器在“Set-Cookie”响应头字段1.7.1中发送的具有指定名称的cookie。仅保存来自最后一个服务器响应的 cookie。$upstream_header_time 保持从上游服务器1.7.10接收响应头所花费的时间时间以毫秒为单位保存。多个响应的时间由逗号和冒号分隔例如 $upstream_addr 变量中的地址。$upstream_http_[name] 保留服务器响应头字段。例如“Server”响应头字段可通过 $upstream_http_server 变量获得。将头域名称转换为变量名称的规则与以“$http_”前缀开头的变量相同。仅保存最后一个服务器响应的标头字段。$upstream_queue_time 保持请求在上游队列中花费的时间1.13.9时间以毫秒为单位保存。多个响应的时间由逗号和冒号分隔例如 $upstream_addr 变量中的地址。商业版提供。$upstream_response_length 保持从上游服务器获得的响应的长度0.7.27长度以字节为单位。几个响应的长度由逗号和冒号分隔如 $upstream_addr 变量中的地址。$upstream_response_time 保持从上游服务器接收响应所花费的时间时间以毫秒为单位保存。多个响应的时间由逗号和冒号分隔例如 $upstream_addr 变量中的地址。$upstream_status 保留从上游服务器获得的响应的状态码。几个响应的状态代码由逗号和冒号分隔如 $upstream_addr 变量中的地址。如果无法选择服务器则该变量会保留 502错误网关状态代码。$upstream_trailer_[name] 保留从上游服务器1.13.10获得的响应末尾的字段。 还是老方法使用一个 log_format 记录所有的这些变量信息就可以查看它们的变化情况。 log_format upstream upstream_addr$upstream_addr upstream_bytes_received$upstream_bytes_received
upstream_bytes_sent$upstream_bytes_sent upstream_cache_status$upstream_cache_status
upstream_connect_time$upstream_connect_time upstream_cookie_a$upstream_cookie_a
upstream_header_time$upstream_header_time upstream_http_server$upstream_http_serverupstream_response_length$upstream_response_length
upstream_response_time$upstream_response_time upstream_status$upstream_status
upstream_trailer_a$upstream_trailer_a;
………………
server{listen 8039;access_log logs/39.log upstream;…………
} 生成的日志是下面这样的。 upstream_addr127.0.0.1:80 upstream_bytes_received854upstream_bytes_sent294 upstream_cache_status-upstream_connect_time0.000 upstream_cookie_a-upstream_header_time0.000 upstream_http_servernginx/1.23.0 upstream_response_length621upstream_response_time0.000 upstream_status200upstream_trailer_a-upstream_addr127.0.0.1:8098 upstream_bytes_received252upstream_bytes_sent294 upstream_cache_status-upstream_connect_time0.000 upstream_cookie_a-upstream_header_time0.001 upstream_http_servernginx/1.23.0 upstream_response_length21upstream_response_time0.001 upstream_status200upstream_trailer_a-upstream_addr192.168.56.89:80 upstream_bytes_received456upstream_bytes_sent294 upstream_cache_status-upstream_connect_time0.001 upstream_cookie_a-upstream_header_time0.002 upstream_http_servernginx/1.23.0 upstream_response_length224upstream_response_time0.002 upstream_status200upstream_trailer_a- 可以看到我请求了三次每次的 upstream_addr 都产生了变化通过这个变量我们就可以看到当前走的是哪台后端服务器。假装挂掉一台将 8098 注释掉或者改下端口号。 upstream_addr127.0.0.1:8098, 192.168.56.89:80 upstream_bytes_received0, 456upstream_bytes_sent0, 294 upstream_cache_status-upstream_connect_time-, 0.000 upstream_cookie_a-upstream_header_time-, 0.001 upstream_http_servernginx/1.23.0 upstream_response_length0, 224upstream_response_time0.001, 0.001 upstream_status502, 200upstream_trailer_a- 日志信息就变成了这样轮询到 8098 时日志在 upstream_addr 中记录了两个 IP 地址由后面的服务器继续提供服务。 配置指令 接下来我们再一个一个的看一下服务器组模块中的配置指令。 upstream 定义一组服务器。 upstream name { ... } 只能定义在 http 模块中服务器可以监听不同的端口。此外侦听 TCP 和 UNIX 域套接字的服务器可以混合使用。 默认情况下请求使用加权循环平衡方法在服务器之间分配。如果在与服务器通信期间发生错误请求将被传递到下一个服务器依此类推直到尝试所有正常运行的服务器。如果无法从任何服务器获得成功响应则客户端将收到与最后一个服务器通信的结果。 server 定义服务器的地址和其他参数。 server address [parameters]; 这个地址可以指定为域名或 IP 地址带有可选端口或指定为“unix:”前缀后指定的 UNIX 域套接字路径。如果未指定端口则使用端口 80。解析为多个 IP 地址的域名一次定义多个服务器。 可以定义以下参数 weightnumber 设置服务器的权重默认为 1。max_connsnumber 限制与代理服务器 (1.11.5) 的同时活动连接的最大数量。默认值为零表示没有限制。如果服务器组不驻留在共享内存中则限制适用于每个工作进程。如果启用了空闲保活连接、多个工作人员和共享内存则与代理服务器的活动和空闲连接总数可能会超过 max_conns 值。max_failsnumber 设置在 fail_timeout 参数设置的持续时间内与服务器通信的不成功尝试次数以考虑服务器在 fail_timeout 参数设置的持续时间内不可用。默认情况下不成功的尝试次数设置为 1。零值禁用尝试记录。被认为是不成功的尝试由 proxy_next_upstream、fastcgi_next_upstream、uwsgi_next_upstream、scgi_next_upstream、memcached_next_upstream 和 grpc_next_upstream 指令定义。fail_timeouttime 与服务器通信的指定次数的不成功尝试碰巧认为服务器不可用的时间以及服务器将被视为不可用的时间段。默认情况下该参数设置为 10 秒。backup 将服务器标记为备份服务器。当主服务器不可用时它将被传递请求。该参数不能与 hash、ip_hash 和 random 负载均衡方法一起使用。down 将服务器标记为永久不可用。 好了这个配置中的这些参数是我们需要重点来测试一下。 先测试权重的效果使用如下配置。 upstream up2 {server 127.0.0.1 weight3;server 127.0.0.1:8098 weight2;server 192.168.56.89;
} 测试的结果就是本地 80 端口的出现次数明显增多8098 端口次之89 服务器的出现次数会比较少。总体来说就是不像前面那样一个一个挨着来了设置的越大出现的频率越高。 接下来测试上下线主要就是 down 和 backup 这两个参数。 upstream up3 {server 127.0.0.1 down;server 127.0.0.1:8098 backup;server 192.168.56.89;
} 现在访问只会一直显示 89 服务器返回的结果为啥呢因为 80 端口服务器被下线 down 了而 8098 端口服务器现在被设置为备用服务器 backup 了。备用服务器平常是不提供访问的如果我们关闭 89 服务器或者将 89 服务器设置为 down 那么再次访问就会显示 8098 端口服务器的内容了。 这些参数可以一起使用比如下面这样。 upstream up4 {server 127.0.0.1 weight10;server 127.0.0.1:8098 weight5 backup;server 192.168.56.89 weight8 down;
} fail_timeout 和 max_fails 不太好测它是服务器超过多长时间没有连接成功不是说我们在后端服务器上加个 sleep() 就能测出来的哦。这个如果大家有怎么测试的方法也请留言告知哦。 hash 使用基于散列键值来进行 Hash 操作的负载均衡方法。 hash key [consistent]; 这个键可以包含文本、变量及其组合。请注意从组中添加或删除服务器可能会导致将大部分密钥重新映射到不同的服务器。该方法与 Cache::Memcached Perl 库兼容。 如果指定了 consistent 参数则将使用 ketama 一致哈希方法。该方法确保在将服务器添加到组或从组中删除时只有少数密钥将重新映射到不同的服务器。这有助于为缓存服务器实现更高的缓存命中率。该方法与将 ketama_points 参数设置为 160 的 Cache::Memcached::Fast Perl 库兼容。 这个一般会用在什么地方呢估计大家马上就想到了变量呀然后可以做 URI 定位的负载均衡嘛。也就是说我们可以通过 $uri 变量来实现不同的 URI 访问到不同的后端主机上。 注意这个是改变均衡策略了使用它如果哈希条件不存在会走轮询如果条件成功就走 Hash 。定义一个配置来测试吧 upstream up7 {hash $uri;server 127.0.0.1;server 127.0.0.1:8098;server 192.168.56.89;
} 测试结果如下 注意如果是相同的 URI 肯定一直走同一台后端主机的。所以我们要用不同的 URI 来测试。 # 访问http://192.168.56.88:8039/
upstream_addr192.168.56.89:80 upstream_bytes_received456upstream_bytes_sent294 upstream_cache_status-upstream_connect_time0.000 upstream_cookie_a-upstream_header_time0.001 upstream_http_servernginx/1.23.0 upstream_response_length224upstream_response_time0.001 upstream_status200upstream_trailer_a-# 访问http://192.168.56.88:8039/aaa.html
upstream_addr192.168.56.89:80 upstream_bytes_received303upstream_bytes_sent302 upstream_cache_status-upstream_connect_time0.000 upstream_cookie_a-upstream_header_time0.001 upstream_http_servernginx/1.23.0 upstream_response_length153upstream_response_time0.001 upstream_status404upstream_trailer_a-# 访问http://192.168.56.88:8039/testkeepalive1.html
upstream_addr127.0.0.1:80 upstream_bytes_received831upstream_bytes_sent313 upstream_cache_status-upstream_connect_time0.000 upstream_cookie_a-upstream_header_time0.000 upstream_http_servernginx/1.23.0 upstream_response_length598upstream_response_time0.000 upstream_status200upstream_trailer_a- 可以看到测试结果前面两个都是走到 89 服务器的最后一个则是走到 88 机的 80 端口这台后端主机上了。 ip_hash 指定组应基于客户端 IP 地址在服务器之间分配请求。 ip_hash; 客户端 IPv4 地址或整个 IPv6 地址的前三个八位字节用作散列密钥。该方法确保来自同一客户端的请求将始终传递到同一服务器除非该服务器不可用。在后一种情况下客户端请求将被传递到另一台服务器。很可能它也将始终是同一台服务器。 从版本 1.3.2 和 1.2.2 开始支持 IPv6 地址。在 1.3.1 和 1.2.2 版本之前无法使用 ip_hash 负载平衡方法为服务器指定权重。 如果需要临时删除其中一台服务器则应使用 down 参数对其进行标记以保留客户端 IP 地址的当前散列。 这个就是另一个均衡策略了也是非常出名的 IP Hash 策略。相同的客户端 IP 会走到同一个服务上。咱们先来配置一个。 upstream up6 {ip_hash;server 127.0.0.1;server 127.0.0.1:8098;server 192.168.56.89;
} 然后进行测试并跟踪日志记录。 # 192.168.56.1 访问
upstream_addr192.168.56.89:80 upstream_bytes_received456upstream_bytes_sent294 upstream_cache_status-upstream_connect_time0.000 upstream_cookie_a-upstream_header_time0.001 upstream_http_servernginx/1.23.0 upstream_response_length224upstream_response_time0.001 upstream_status200upstream_trailer_a-# 192.168.56.89 访问
89[rootlocalhost ~]# curl http://192.168.56.88:8039
upstream_addr192.168.56.89:80 upstream_bytes_received456upstream_bytes_sent86 upstream_cache_status-upstream_connect_time0.000 upstream_cookie_a-upstream_header_time0.001 upstream_http_servernginx/1.23.0 upstream_response_length224upstream_response_time0.001 upstream_status200upstream_trailer_a-…………………… 额貌似请求全打到 89 这台服务器了不管你开多少虚拟机都一样。难道本地有问题吗其实呀Nginx 的 IP Hash 使用的是 IP 段的前三位。而我们在同一台机器上IP 段都是一样的。这就不好测了要本地做多个虚拟网络并且添加网卡比较麻烦。其实最简单的还是有条件的同学就买个云服务器然后在云服务器上测试吧。 或者使用另一个方案就是直接用上面的 hash 方式然后键值直接使用 $remote_addr 就好啦。 这个均衡策略有啥好处呢最典型的一个案例就是它是解决服务器集群 session 保存问题的方案之一。假设我们使用的是轮询session 也是 PHP 默认的方案那么第一次访问的 session 会保存到服务器1的 session 目录下。下一次访问轮询到另一台服务器上了这台服务器没有这个 session 文件自然 session 也就失效了。而 IP Hash 则保证每次都进入到同一台后端服务器这样就解决了。 当然这只是解决 session 问题的一个最简单的方案现在更流行的其实是直接使用外部存储如 Redis 来保存 session 不管你使用啥均衡策略Redis 不变就行啦。 keepalive 激活缓存以连接到上游服务器。 keepalive connections; 连接参数设置保留在每个工作进程缓存中的上游服务器的最大空闲保活连接数。当超过这个数字时最近最少使用的连接将被关闭。 需要特别注意的是keepalive 指令不限制 nginx 工作进程可以打开的上游服务器的连接总数。连接参数应该设置为一个足够小的数字以便上游服务器也可以处理新的传入连接。 当使用默认循环方法以外的负载平衡方法时需要在 keepalive 指令之前激活它们。 对于 HTTPproxy_http_version 指令应设置为“1.1”并且应清除“Connection”标头字段。或者可以通过将“Connection: Keep-Alive”标头字段传递给上游服务器来使用 HTTP/1.0 持久连接但不建议使用此方法。 对于 FastCGI 服务器需要设置 fastcgi_keep_conn 才能使 keepalive 连接正常工作。SCGI 和 uwsgi 协议没有保持连接的概念。 这个测试我们直接通过 89 服务器产生的连接数来看一下。先准备这样的配置文件按文档说明配置好。 upstream up9 {server 127.0.0.1;server 127.0.0.1:8098;server 192.168.56.89;keepalive 16;
}server{listen 8039;access_log logs/39.log upstream;location / {proxy_pass http://up9;proxy_http_version 1.1;proxy_set_header Connection ;}
} 然后看测试效果使用 Jmeter 或者 ab 工具进行压测如果不使用长连接的话查看 89 服务器的连接数量。 [rootlocalhost ~]# netstat -nat|grep -i 80 | wc -l
3331 在访问的时候建立了 3331 个 TCP 连接而使用长连接后。 [rootlocalhost ~]# netstat -nat|grep -i 80 | wc -l
23 只建立了 23 个效果还是比较明显的吧。 关于 Jmeter 工具之前在讲 HTTP 核心模块的长连接时有过简单介绍不记得的小伙伴可以回去看下哦。 keepalive_requests 设置可以通过一个 keepalive 连接服务的最大请求数。 keepalive_requests number; 默认值 1000 在发出最大请求数后连接将关闭。定期关闭连接对于释放每个连接的内存分配是必要的。因此使用过高的最大请求数可能会导致内存使用过多不推荐使用。在 1.19.10 版本之前默认值为 100。 keepalive_time 限制通过一个保活连接处理请求的最长时间。 keepalive_timeout timeout; 默认值 60s 达到这个时间后连接在后续请求处理后关闭。 keepalive_timeout 设置一个超时时间在此期间与上游服务器的空闲保活连接将保持打开状态。 keepalive_timeout timeout; 默认值 60s 。 least_conn 指定组应使用最少活动连接数的服务器同时考虑服务器的权重。 least_conn; 如果有多个这样的服务器则使用加权循环平衡方法依次尝试它们。 这个均衡策略的效果不太好测它是根据哪个服务器建立的连接最少就使用哪个服务器来进行连接的。可以达到的效果是保证所有后端服务器的连接数均衡。不会有某个服务器承担特别重的任务其它服务器又特别清闲。有兴趣或者知道怎么测试的小伙伴可以自己试试哦。 random 指定组应使用负载平衡方法其中将请求传递到随机选择的服务器同时考虑服务器的权重。 random [two [method]]; 可选的 two 参数指示 nginx 随机选择两个服务器然后使用指定的方法选择一个服务器。默认方法是 minimum_conn 它将请求传递给活动连接数最少的服务器。 least_time 方法将请求传递给平均响应时间最短且活动连接数最少的服务器。如果指定了 minimum_timeheader则使用接收响应头的时间。如果指定了 minimum_timelast_byte则使用接收完整响应的时间。不过这个参数是商业版才有的。 最后的这个配置指令也是一个均衡策略它就是随机的拿一台出来没有什么特别的规则。 upstream up5 {random;server 127.0.0.1;server 127.0.0.1:8098;server 192.168.56.89;
} 效果大家自己测试一下吧。 商业配置指令 除了上面的配置外在这个模块中还有不少商业版才提供的配置项这里我们就列出来没法进行测试了大家了解下就好。 server 中的 resolve、route、service、slow_start、drain参数random 中的 least_time 参数zone、state、ntlm、least_time、queue、resolver、resolver_timeout、sticky、sticky_cookie_insert 配置指令 同时写两个负载均衡方式 文章的最后我们再来看看假如我们写多个均衡策略会有什么效果呢比如下面这样。 upstream up8 {hash $arg_b;hash $arg_a;server 127.0.0.1;server 127.0.0.1:8098;server 192.168.56.89;
} 在重载配置时会报出警告。 [rootlocalhost article.http.d]# nginx -s reload
nginx: [warn] load balancing method redefined in /etc/nginx/article.http.d/39.conf:57 注意这里是警告表示这样配是可以用的。直接访问的话会发现结果是以后面配置的的为准。不带 a 参数时走轮询带了 a 参数按 a 参数 hash 。b 参数即使指定了也不生效还是默认轮询也就是第二个 hash 配置的 Key 不存在时走默认的。 总结 今天的内容怎么样这个模块其实非常容易在面试时出考点比如说问你 Nginx 的负载均衡策略都有哪些呀现在咱们可以自信地马上就说出 轮询、Hash、IP Hash、最少连接、随机 这五种了吧。另外再问你权重是啥意思IP Hash 有什么应用场景相信这些问题都难不到你了。 到此为止其实整个 Nginx 最核心的部分学习就结束了。后面还有两篇文章就是一些额外的小东西了不过还是不要松解哦小东西不代表不重要而且可能还是面试时经常出现的高频问题哦。 参考文档 http://nginx.org/en/docs/http/ngx_http_upstream_module.html
