大佬教程收集整理的这篇文章主要介绍了nginx七层负载均衡，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
负载均衡（Load Balance） c;指的是将用户访问请求所产生的流量c;进行平衡c;分摊到多个应用节点处理。负载均衡扩展了应用节点的服务能力c;增强了应用服务器的可用性。
当我们的 Web服务器直接面向用户c;往往要承载大量并发请求c;单台服务器难以负荷c;我们可以使用多台 WEB 服务器组成集群c;前端使用 Nginx 负载均衡c;将请求分散的分发到我们的后端服务器集群中c;实现负载的流量分发。从而提升整体性能、以及系统的容灾能力。
四层负载均衡指的是 OSI 七层模型中的传输层c;四层仅需要对客户端的请求进行TCP/IP协议包代理就可以实现负载均衡。IP+Port四层负载均衡的性能极好、因为只需要底层进行转发处理c;而不需要进行一些复杂的逻辑。
七层负载均衡工作在应用层c;它可以完成很多应用方面的协议请求c;比如我们说的 http 应用负载均衡c;它可以实现 http 头信息的改写、安全应用规则控制、URI 匹配规则控制、及 rewrite 等功能c;在应用层里面可以做的内容比较丰富。
四层负载均衡：传输层 优点：性能高c;数据包在底层就进行了转发（LVS）c;基于LVS的四层代理不需要占用端口c;基于nginx的四层代理需要占用端口。 缺点：仅支持ip:prot转发c;无法完成复杂的业务逻辑应用。
七层负载均衡：应用层 优点：贴近业务c;支持 URI路径匹配、Header改写、Rewrite等 缺点：性能低c;数据包需要拆解到顶层才进行调度c;消耗随机端口； 应用场景：MySQL TCP 3306c; redis、SSH、等代理
Nginx 实现负载均衡需要两个模块： proxy_pass 代理模块 (proxy_modules) upstream 虚拟资源池模块(proxy_upstream_modulE)
Syntax: upstream name { ... }
Default: -
Context: http
| 角色 | 外网IP(NAT) | 内网IP(LAN) | 主机名 |
|---|---|---|---|
| LB01 | eth0:10.0.0.5 | eth1:172.16.1.5 | lb01 |
| web01 | eth0:10.0.0.7 | eth1:172.16.1.7 | web01 |
| web02 | eth0:10.0.0.8 | eth1:172.16.1.8 | web02 |
1.Web01 服务器上配置为应用服务节点, 创建对应 html 文件
[root@web01 conf.d]# cat web01.conf
server {
listen 80;
server_name web.bertwu.net;
root /code/web;
LOCATIOn / {
index index.html;
}
}
[root@web01 conf.d]# mkdir /code/web
[root@web01 conf.d]# echo 'web01 ip:172.16.1.7' > /code/web/index.html
[root@web01 conf.d]# systemctl restart nginx
2.Web02 服务器上配置为应用服务节点, 创建对应 html 文件
[root@web02 conf.d]# cat web02.conf
server {
listen 80;
server_name web.bertwu.net;
root /code/web;
LOCATIOn / {
index index.html;
}
}
[root@web02 conf.d]# mkdir /code/web
[root@web02 conf.d]# echo 'web02 ip:172.16.1.8' > /code/web/index.html
[root@web02 conf.d]# systemctl reload nginx
实际生产环境中c;每个节点的代码都一模一样c;这里方便测试c;index.html才写的不同的内容。
[root@lb01 conf.d]# cat proxy_web.conf
upstream web {
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
[root@lb01 conf.d]# nginx -t
[root@lb01 conf.d]# systemctl reload nginx
proxy_params参数文件如下：
[root@lb01 nginx]# cat proxy_params
# ip
proxy_set_header Host $http_host;
proxy_set_header X-ForWARDed-For $proxy_add_x_forWARDed_for;
# http @H_255_489@version
proxy_http_version 1.1;
proxy_set_header Connection "";
# timeout
proxy_connect_timeout 120s;
proxy_read_timeout 120s;
proxy_send_timeout 120s;
# buffer
proxy_buffering on;
proxy_buffer_size 8k;
proxy_buffers 8 8k;
配置本地hosts文件
10.0.0.5 web.bertwu.net
使用浏览器访问 web.bertwu.comc;然后进行刷新测试。
可以看到c;他们交替出现c;说明每次请求后负载均衡的确调度到不同的web节点来处理。
# 负载均衡服务器配置
[root@lb01 conf.d]# cat proxy_blog.conf
upstream blog {
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name blog.bertwu.net;
LOCATIOn / {
proxy_pass http://blog;
include /etc/nginx/proxy_params;
}
}
后端web服务器代码不变。
# web@H_255_489@01配置
[root@web01 conf.d]# cat wordpress.conf
server {
listen 80;
server_name blog.bertwu.net;
client_max_body_size 100@H_73_140@m;
root /code/wordpress;
charset utf-8;
LOCATIOn / {
index index.php index.html;
}
LOCATIOn ~ .*.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILename $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
}
# web@H_255_489@02配置
[root@web02 conf.d]# cat wordpress.conf
server {
listen 80;
server_name blog.bertwu.net;
client_max_body_size 100@H_73_140@m;
root /code/wordpress;
charset utf-8;
LOCATIOn / {
index index.php index.html;
}
LOCATIOn ~ .*.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILename $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}
}
| 调度算法 | 概述 |
|---|---|
| 轮询调度算法 | 按时间顺序逐一分配到不同的后端服务器(默认) |
| weight | 加权轮询,weight值越大,分配到的访问几率越高 |
| ip_hash | 每个请求按访问IP的hash结果分配（根据节点的个数取模）,这样来自同一IP的固定访问一个后端服务器 |
| 一致性hash | 不根据节点的个数取模c;对2@H_253_874@32 取模 |
| url_hash | 根据请求uri进行调度到指定节点 |
| least_conn | 将请求传递到活动连接数最少的服务器。 |
轮询调度算法的原理是将每一次用户的请求c;轮流分配给内部资源池中的服务器。轮询算法的优点是其简洁性c;它无需记录当前所有连接的状态c;所以它是一种无状态调度。
upstream web {
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
轮询调度算法没有考虑每台服务器的处理能力c;在实际情况中c;由于每台服务器的配置、安装的业务应用等不同c;其处理能力会不一样。所以c;我们根据服务器的不同处理能力c;给每个服务器分配不同的权值c;使其能够接受相应权值数的服务请求。
```c
upstream web {
server 172.16.1.7:80 weight=5;
server 172.16.1.8:80 weight=1;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
ip_hash 是基于用户请求的IPc;对该 IP 进行 hash 运算c;根据 hash运算的值c;将请求分配到后端特定的一台节点进行处理。ip_hash 算法实现公式：hash(ip) % node_counts = index
配置 ip_hash 调度算法
upstream web {
ip_hash;
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
ip_hash 调度算法会带来两个问题
为了规避上述hash情况c;一致性hash算法就诞生c;一致性Hash算法也是使用取模的方法c;但不是对服务器节点数量进行取模c;而是对2的32方取模。即c;一致性Hash算法将整个Hash空间组织成一个虚拟的圆环c;Hash函数值的空间为0 ~ 2^32 - 1c;整个哈希环如下：
@H_618_1123@
一致性哈希是顺时针的c;管增加节点还是下线节点影响的永远是局部（圆环的某一部分）c;而不是全局c;而ip_hash不管增加节点还是下线节点c;都影响的是全局。
在一致性Hash算法服务节点太少的情况下c;容易因为节点分布不均匀面造成数据倾斜（被缓存的对象大部分缓存在某一台服务器上）问题
一致性hash参考文档 语法：
Syntax: hash key [consistent];
Default: —
Context: upstream
This directive appeared in version 1.7.2.
示例：
```c
upstream web {
# ip@H_255_489@_hash; # 基于ip hash取模的方式
hash $remote_addr consistent; # 基于ip的一致性hash
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
注意：ip_hash如果用内网访问c;有课能永远只会调度到某个节点c;不会均摊c;这是因为官方给出的解释： Specifies that a group should use a load balancing method where requests are diStributed between servers based on client IP addresses. The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavailable. In the latter case client requests will be passed to another server. Most probably, it will always be the same server as well 也就是用ip地址的前三段作为key ,如果内网的前三段相同c;那么当然算出来的值就相同c;这样就只能调度到特定节点。
根据用户请求的 URL 进行 hash 取模c;根据 hash运算的值c;将请求分配到后端特定的一台节点进行处理。URL 算法使用场景如下：client–>nginx–>url_hash–>cache1–>app 1.用户请求nginx负载均衡器c;通过 url 调度算法c;将请求调度至Cache1 2.由于 Cache1 节点没有对应的缓存数据c;则会请求后端获取c;然后返回数据c;并将数据缓存起来； 3.当其他用户再次请求此前相同的 URL 时c;此时调度器依然会调度至 Cache1 节点处理； 4.由于 Cache1 节点已存在该URL资源缓存c;所以直接将缓存数据进行返回；能大幅提升网站的响应；
# 负载均衡服务器配置
root@lb01 conf.d]# cat url_hash.conf
upstream load_pass {
hash $request_uri consistent; # 对uri进行hash,使用一致性hash算法
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name url_hash.bertwu.net;
LOCATIOn / {
proxy_pass http://load_pass;
include /etc/nginx/proxy_params;
}
}
# web@H_255_489@01服务器配置
[root@web01 conf.d]# cat url_hash.conf
server {
listen 80;
server_name url_hash.bertwu.net;
root /code/url_hash;
LOCATIOn / {
index index.html;
}
}
[root@web01 conf.d]# mkdir /code/url_hash
[root@web01 conf.d]# cat /code/url_hash/url1.html
web01 url01
[root@web01 conf.d]# cat /code/url_hash/url2.html
web01 url02
# web@H_255_489@02服务器配置
[root@web02 conf.d]# cat url_hash.conf
server {
listen 80;
server_name url_hash.bertwu.net;
root /code/url_hash;
LOCATIOn / {
index index.html;
}
}
[root@web01 conf.d]# mkdir /code/url_hashl
[root@web02 ~]# cat /code/url_hash/url1.html
web02 url01
[root@web02 ~]# cat /code/url_hash/url2.html
web02 url02
客户端换任何ip访问也是一样c;因为它只基于uri调度。
[root@nfs ~]# curl -H Host:url_hash.bertwu.net http://10.0.0.5/url1.html
web02 url01
[root@nfs ~]# curl -H Host:url_hash.bertwu.net http://10.0.0.5/url2.html
web01 url02
least_conn调度算法实现原理c;哪台节点连接数少c;则将请求调度至哪台节点。假设：A节点有1000个连接 ,b节点有500连接c;如果此时新的连接进入会分发给b节点
upstream load_pass {
least_conn;
server 172.16.1.7:80;
server 172.16.1.8:80;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://load_pass;
include /etc/nginx/proxy_params;
}
}
后端 Web 节点在前端 Nginx 负载均衡调度中的状态如下：
| 状态 | 概述 |
|---|---|
| down | 当前的server暂时不参与负载均衡 |
| BACkup | 预留的备份服务器 |
| 允许请求失败的次数 | |
| fail_timeout | 经过max_fails失败后, 服务暂停时间 |
| 限制最大的接收连接数 |
[root@lb01 conf.d]# cat proxy_web.conf
upstream web {
server 172.16.1.7:80 down; # 一般用于停机维护
server 172.16.1.8:80;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
BACkup 将服务器标记为备份服务器。当主服务器不可用时c;将请求传递至备份服务器处理。
upstream web {
server 172.16.1.7:80;
server 172.16.1.8:80 BACkup; # 只有所有其他节点故障时候它才启用
server 172.16.1.9:80;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
[root@lb01 conf.d]# cat proxy_web.conf
upstream web {
server 172.16.1.7:80 max_conns=2;
server 172.16.1.8:80 max_conns=2;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
通过 jmter 压力测试发现c;当后端节点处理的连接数非常多的时候c;当大于4个连接c;其余的连接则会抛出异常c;也就是每次仅能满足4个连接。
upstream web {
server 172.16.1.7:80 max_files=2 file_timeout=5s;
server 172.16.1.8:80 max_conns=2 file_timeout=5s;
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
include proxy_params;
}
}
keepalive 主要是与后端服务器激活缓存c;也就是长连接c;主要用来提升网站吞吐量。默认情况下：没有与后端服务启用长连接功能(http 1.0协议)c;当有请求时c;需要建立连接、维护连接、关闭连接c;所以会存在网络消耗。但如果启用长连接c;且将所有的连接都缓存了c;当连接空闲了又会占用其系统资源c;所以可以使用 keepalive 参数来激活缓存的同时c;还可以使用 keepalive 参数来限制最大的空闲连接数。
配置 Nginx 负载均衡启用 keepalive 参数：
[root@lb01 conf.d]# cat proxy_web.conf
upstream web {
server 172.16.1.7:80;
server 172.16.1.8:80;
keepalive 16; # 最大空闲连接数c;超过就被回收
keepalive_timeout 100s; # 空闲连接的超时时间
}
server {
listen 80;
server_name web.bertwu.net;
LOCATIOn / {
proxy_pass http://web;
#include @H_255_489@proxy_params;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $http_host;
}
}
以上是大佬教程为你收集整理的nginx七层负载均衡全部内容，希望文章能够帮你解决nginx七层负载均衡所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。