Nginx 从入门到入坟(十三)- 负载均衡的原理及优化
1. 负载均衡概述
早期的网站流量和业务功能都比较简单,单台服务器足以满足基本的需求,但是随着互联网的发展,业务流量越来越大并且业务逻辑也跟着越来越复杂,单台服务器的性能及单点故障问题就凸显出来了,因此需要多台服务器进行性能的水平扩展及避免单点故障出现。那么如何将不同用户的请求流量分发到不同的服务器上呢?
负载均衡就是在这样的场景下产生的。
2. 负载均衡的原理及处理流程
系统的扩展可以分为纵向扩展和横向扩展。
- 纵向扩展: 从单机的角度出发,通过增加系统的硬件处理能力来提升服务器的处理能力。
- 横向扩展: 通过添加机器来满足大型网站服务的处理能力。
而负载均衡就是在横向扩展的前提下,根据服务器硬件的实际情况 “公平” 的向他们分发请求。
这里面涉及到两个重要的角色分别是 “应用集群” 和 “负载均衡器”。
- 应用集群: 将同一应用部署到多台机器上,组成处理集群,接收负载均衡设备分发的请求,进行处理并返回响应的数据。
- 负载均衡器: 将用户访问的请求根据对应的负载均衡算法,分发到集群中的一台服务器进行处理。
2.1 负载均衡的作用
- 解决服务器的高并发压力,提高应用程序的处理性能,如果客户端的流量过多的话,有可能会导致服务器的反应速度减慢,所以需要将客户端的流量分摊到其他各种服务器上。
- 提供故障转移,实现高可用,还能够监测数据安全,通过其内置功能自动隔离有异常情况的主机,以此来保护数据的安全,如果出现了问题就会直接将问题主机直接替换掉。
- 通过添加或减少服务器数量,增强网站的可扩展性。
- 在负载均衡器上提前进行过滤,可以提高系统的安全性。
2.2 负载均衡常用的处理方式
2.2.1 用户手动选择
这种方式比较原始,实现的方式就是在网站主页上面提供不同线路、不同服务器链接方式,让用户来选择自己访问的具体服务器,来实现负载均衡。
早些时候的人们,就是通过这种方式来下载小电影之类的资源:smirk:
2.2.2 DNS轮询方式
域名系统(服务)协议(DNS)是一种分布式网络目录服务,主要用于域名与 IP 地址的相互转换。
大多域名注册商都支持对同一个主机名添加多条 A 记录,这就是 DNS 轮询,DNS 服务器将解析请求按照 A 记录的顺序,随机分配到不同的 IP 上,这样就能完成简单的负载均衡。DNS 轮询的成本非常低,在一些不重要的服务器,被经常使用。
虽然 DNS 轮询成本低廉,但是 DNS 负载均衡存在明显的缺点:
- 可靠性低
- 假设一个域名 DNS 轮询多台服务器,如果其中的一台服务器发生故障,那么所有的访问该服务器的请求将不会有所回应,即使你将该服务器的 IP 从 DNS 中去掉,但是由于各大宽带接入商将众多的 DNS 存放在缓存中,以节省访问时间,导致 DNS 不会实时更新。所以 DNS 轮询一定程度上解决了负载均衡问题,但是却存在可靠性不高的缺点。
- 负载均衡不均衡
- DNS 负载均衡采用的是简单的轮询负载算法,不能区分服务器的差异,不能反映服务器的当前运行状态,不能做到为性能好的服务器多分配请求,另外本地计算机也会缓存已经解析的域名到 IP 地址的映射,这也会导致使用该 DNS 服务器的用户在一定时间内访问的是同一台 Web 服务器,从而引发 Web 服务器的负载不均衡。
- 负载不均衡则会导致某几台服务器负荷很低,而另外几台服务器负荷确很高,处理请求的速度慢,配置高的服务器分配到的请求少,而配置低的服务器分配到的请求多。
2.2.3 四/七层负载均衡
介绍四/七层负载均衡之前,我们先了解一个概念,OSI(open system interconnection),叫开放式系统互联模型
,这个是由国际标准化组织 ISO 指定的一个不基于具体机型、操作系统或公司的网络体系结构。该模型将网络通信的工作分为七层。
- 应用层: 为应用程序提供网络服务。
- 表示层: 对数据进行格式化、编码、加密、压缩等操作。
- 会话层: 建立、维护、管理会话连接。
- 传输层: 建立、维护、管理端到端的连接,常见的有 TCP/UDP。
- 网络层: IP 寻址和路由选择
- 数据链路层: 控制网络层与物理层之间的通信。
- 物理层: 比特流传输。
所谓四层负载均衡指的是 OSI 七层模型中的传输层,主要是基于 IP+PORT 的负载均衡在三层负载均衡的基础上,通过发布三层的 IP 地址,然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行 NAT 处理,转发至后台服务器,并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理:
1 | 实现四层负载均衡的方式: |
所谓的七层负载均衡指的是在应用层,主要是基于虚拟的 URL 或主机 IP 的负载均衡,在四层负载均衡的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,比如同一个 Web 服务器的负载均衡,除了根据 IP 加 80 端口辨别是否需要处理的流量,还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,如果你的 Web 服务器分成两组,一组是中文语言的,一组是英文语言的,那么七层负载均衡就可以当用户来访问你的域名时,自动辨别用户语言,然后选择对应的语言服务器组进行负载均衡处理:
1 | 实现七层负载均衡的方式: |
四层和七层负载均衡的区别:
- 四层负载均衡数据包是在底层就进行了分发,而七层负载均衡数据包则在最顶端进行分发,所以四层负载均衡的效率比七层负载均衡的要高。
- 四层负载均衡不识别域名,而七层负载均衡识别域名。
- 四层负载均衡本质是转发,而七层负载本质是内容交换和代理。
还有二层、三层负载均衡,二层是在数据链路层基于 mac 地址来实现负载均衡,三层是在网络层一般采用虚拟 IP 地址的方式实现负载均衡。
而实际环境中一般采用四层负载(LVS)+七层负载(Nginx)
的模式。
3. Nginx七层负载均衡
Nginx 要实现七层负载均衡需要用到proxy_pass
代理模块配置。Nginx 默认安装支持这个模块,我们不需要再做任何处理。Nginx 的负载均衡是在 Nginx 的反向代理基础上把用户的请求根据指定的算法分发到一组upstream虚拟服务池
。
3.1 Nginx七层负载均衡的指令
3.1.1 upstream指令
该指令是用来定义一组服务器,它们可以是监听不同端口的服务器,并且也可以是同时监听 TCP 和 Unix socket 的服务器。服务器可以指定不同的权重,默认为 1。
语法 | upstream name {…} |
---|---|
默认值 | — |
位置 | http |
3.1.1 server指令
该指令用来指定后端服务器的名称和一些参数,可以使用域名、IP、端口或者 unix socket。
语法 | server name [paramerters] |
---|---|
默认值 | — |
位置 | upstream |
3.2 Nginx七层负载均衡的实现流程
服务端设置:
1 | server { |
负载均衡器设置:
1 | upstream backend{ |
3.3 负载均衡状态
代理服务器在负责均衡调度中的状态有以下几个:
状态 | 概述 |
---|---|
down | 当前的 server 暂时不参与负载均衡 |
backup | 预留的备份服务器 |
max_fails | 允许请求失败的次数 |
fail_timeout | 经过 max_fails 失败后, 服务暂停时间 |
max_conns | 限制最大的接收连接数 |
3.3.1 down
将该服务器标记为永久不可用,那么该代理服务器将不参与负载均衡。
1 | upstream backend{ |
该状态一般会对需要停机维护的服务器进行设置。
3.3.2 backup
将该服务器标记为备份服务器,当主服务器不可用时,将用来传递请求。
1 | upstream backend{ |
此时需要将 9094 端口的访问禁止掉来模拟下唯一能对外提供访问的服务宕机以后,backup 的备份服务器就要开始对外提供服务,此时为了测试验证,我们需要使用防火墙来进行拦截。
介绍一个工具firewall-cmd
,该工具是 Linux 提供的专门用来操作 firewall 的。
- 查询防火墙中指定的端口是否开放:
1
firewall-cmd --query-port=9001/tcp
- 如何开放一个指定的端口
1
firewall-cmd --permanent --add-port=9002/tcp
- 批量添加开发端口
1
firewall-cmd --permanent --add-port=9001-9003/tcp
- 如何移除一个指定的端口
1
firewall-cmd --permanent --remove-port=9003/tcp
- 重新加载
1
firewall-cmd --reload
--permanent
表示设置为持久。--add-port
表示添加指定端口。--remove-port
表示移除指定端口。
3.3.3 max_conns
max_conns=number: 用来设置代理服务器同时活动链接的最大数量,默认为 0,表示不限制,使用该配置可以根据后端服务器处理请求的并发量来进行设置,防止后端服务器被压垮。
3.3.4 max_fails和fail_timeout
max_fails=number: 设置允许请求代理服务器失败的次数,默认为 1。
fail_timeout=time: 设置经过 max_fails 失败后,服务暂停的时间,默认是 10 秒。
1 | upstream backend{ |
3.4 Nginx负载均衡策略
介绍完 Nginx 负载均衡的相关指令后,我们已经能实现将用户的请求分发到不同的服务器上,那么除了采用默认的分配方式以外,我们还能采用什么样的负载算法?
Nginx 的 upstream 支持如下六种方式的分配算法,分别是:
算法名称 | 说明 |
---|---|
轮询 | 默认方式 |
weight | 权重方式 |
ip_hash | 依据ip分配方式 |
least_conn | 依据最少连接方式 |
url_hash | 依据URL分配方式 |
fair | 依据响应时间方式 |
3.4.1 轮询
是 upstream 模块负载均衡默认的策略。每个请求会按时间顺序逐个分配到不同的后端服务器。轮询不需要额外的配置。
1 | upstream backend{ |
3.4.2 weight加权(加权轮询)
用来设置服务器的权重,默认为 1,权重数据越大,被分配到请求的几率越大;该权重值,主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的,所有此策略比较适合服务器的硬件配置差别比较大的情况。
1 | upstream backend{ |
3.4.3 ip_hash
当对后端的多台动态应用服务器做负载均衡时,ip_hash 指令能够将某个客户端 IP 的请求通过哈希算法定位到同一台后端服务器上。这样,当来自某一个 IP 的用户在后端 Web 服务器 A 上登录后,在访问该站点的其他 URL,能保证其访问的还是后端 web 服务器 A。
语法 | ip_hash |
---|---|
默认值 | — |
位置 | upstream |
1 | upstream backend{ |
需要注意的是使用 ip_hash 指令无法保证后端服务器的负载均衡,可能导致有些后端服务器接收到的请求多,有些后端服务器接收的请求少,而且设置后端服务器权重等方法将不起作用。
3.4.4 least_conn
最少连接,把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端,使它们的负载大致相同;但是,有些请求占用的时间很长,会导致其所在的后端负载较高。这种情况下,least_conn 这种方式就可以达到更好的负载均衡效果。
1 | upstream backend{ |
此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。
3.4.5 url_hash
按访问 url 的 hash 结果来分配请求,使每个 url 定向到同一个后端服务器,要配合缓存命中来使用。同一个资源多次请求,可能会到达不同的服务器上,导致不必要的多次下载,缓存命中率不高,以及一些资源时间的浪费。而使用 url_hash,可以使得同一个 url(也就是同一个资源请求)会到达同一台服务器,一旦缓存住了资源,再此收到请求,就可以从缓存中读取。
1 | upstream backend{ |
3.4.6 fair
fair 采用的不是内建负载均衡使用的轮换的均衡算法,而是可以根据页面大小、加载时间长短智能的进行负载均衡。那么如何使用第三方模块的 fair 负载均衡策略:
1 | upstream backend{ |
但是如何直接使用会报错,因为 fair 属于第三方模块实现的负载均衡。需要添加nginx-upstream-fair
,如何添加对应的模块:
- 下载
nginx-upstream-fair
模块1
2下载地址为:
https://github.com/gnosek/nginx-upstream-fair - 将下载的文件上传到服务器并进行解压缩
1
unzip nginx-upstream-fair-master.zip
- 重命名资源
1
mv nginx-upstream-fair-master fair
- 使用
./configure
命令将资源添加到 Nginx 模块中1
./configure --add-module=/root/fair
- 编译 编译可能会出现如下错误,
1
make
ngx_http_upstream_srv_conf_t
结构中缺少default_port
解决方案:
在 Nginx 的源码中src/http/ngx_http_upstream.h
,找到ngx_http_upstream_srv_conf_s
,在模块中添加添加default_port
属性:1
in_port_t default_port
然后再进行 make - 将 sbin 目录下的 nginx 进行备份
1
mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginxold
- 将安装目录下的 objs 中的 nginx 拷贝到 sbin 目录
1
2cd objs
cp nginx /usr/local/nginx/sbin - 更新 Nginx
1
2cd ../
make upgrade - 编译测试使用 Nginx
上面介绍了 Nginx 常用的 6 种负载均衡的策略,那么在咱们以后的开发中到底使用哪种,这个需要根据实际项目的应用场景来决定的。
4. 负载均衡案例
4.1 案例一:对所有请求实现一般轮询规则的负载均衡
1 | upstream backend{ |
4.2 案例二:对所有请求实现加权轮询规则的负载均衡
1 | upstream backend{ |
4.3 案例三:对特定资源实现负载均衡
1 | upstream videobackend{ |
4.4 案例四:对不同域名实现负载均衡
1 | upstream itcastbackend{ |
4.5 案例五:实现带有URL重写的负载均衡
1 | upstream backend{ |
5. Nginx四层负载均衡
Nginx 四层负载均衡就是实现通过访问某个 IP 的端口转发至对应的服务器上。
5.1 Nginx四层负载均衡的指令
5.1.1 stream指令
该指令提供在其中指定流服务器指令的配置文件上下文,和 http 指令同级。
语法 | stream { … } |
---|---|
默认值 | — |
位置 | main |
5.1.2 upstream指令
该指令和 http 的 upstream 指令是类似的。
5.2 Nginx四层负载均衡的案例
实现步骤:
准备 Redis 服务器,在一条服务器上准备三个 Redis,端口分别是 6379,6378。
- 上传 redis 的安装包,redis-4.0.14.tar.gz
- 将安装包进行解压缩
1
tar -zxf redis-4.0.14.tar.gz
- 进入 redis 的安装包
1
cd redis-4.0.14
- 使用 make 和 install 进行编译和安装
1
make PREFIX=/usr/local/redis/redis01 install
- 拷贝 redis 配置文件
redis.conf
到/usr/local/redis/redis01/bin
目录中1
cp redis.conf /usr/local/redis/redis01/bin
- 修改
redis.conf
配置文件1
2port 6379 #redis的端口
daemonize yes #后台启动redis - 将 redis01 复制一份为 redis0
1
2cd /usr/local/redis
cp -r redis01 redis02 - 对 redis02 文件夹中的
redis.conf
进行修改1
2port 6378 #redis的端口
daemonize yes #后台启动redis - 分别启动,即可获取两个 Redis 使用 Nginx 将请求分发到不同的 Redis 服务器上。
1
ps -ef | grep redis
准备 Tomcat 服务器:
- 上传 tomcat 的安装包,apache-tomcat-8.5.56.tar.gz
- 将安装包进行解压缩
1 | tar -zxf apache-tomcat-8.5.56.tar.gz |
- 进入 tomcat 的
bin
目录
1 | cd apache-tomcat-8.5.56/bin |
nginx.conf 配置:
1 | stream { |
参考文献
【1】https://www.bilibili.com/video/BV1ov41187bq?p=93
【2】https://kb.cnblogs.com/page/559213/
【3】https://blog.z0ukun.com/?p=793
【4】https://mp.weixin.qq.com/s?__biz=Mzg3ODAyNDI0OQ==&mid=2247484047&idx=1&sn=ffce58518ca1e439dad22033a0295f44&chksm=cf1b41d9f86cc8cf97f34f736e7e61c7eae1d5e379abbfde2e074be0c418a2a4302301afdd6d&mpshare=1&scene=23&srcid=&sharer_sharetime=1587997041653&sharer_shareid=6d0541e301a4fa3892dd3e84730e5ada#rd
【5】http://www.yujujie.cn/shbk/40691.html
【6】https://www.yisu.com/zixun/22329.html
【7】https://blog.csdn.net/Kangyucheng/article/details/90673399
【8】https://blog.51cto.com/jiangxl/5283968