- LVS+Keepalived+Nginx负载均衡搭建测试
- 负载均衡层设计方案例子
-
负载均衡分类
-
- 地理级别的均衡
- 集群级别的负载均衡
- 机器级别的负载均衡
-
负载均衡服务器和业务服务器之间连接和交互
- 连接建立
- 连接检测
- 连接中断后的处理
-
负载均衡集群
在运算系统集群 或 存储系统集群 或 缓存系统集群都要用到负载均衡
在架构中加入负载均衡系统，负载均衡系统可以使用的位置：可以使用在web应用服务之前，也可用在数据库集群前（如：在MySQL集群中，使用LVS将数据库请求分散到各个从服务器）。
**单个任务负载均衡分配器复杂度 **
N个任务负载均衡分配器的复杂度
DNS 是最简单也是最常见的负载均衡方式，一般用来实现地理级别的均衡，DNS 负载均衡的本质是DNS 解析同一个域名可以返回不同的IP 地址
【优点】
( I ）简单、成本低： 负载均衡工作交给DNS 服务器处理，无须自己开发或维护负载均衡设备。
( 2 ）就近访问，提升访问速度： DNS 解析时可以根据请求来源IP ，解析成距离用户最近的服务器地址，可以加快访问速度， 改善性能。
【缺点】
(1）更新不及时： DNS 缓存的时间比较长，修改DNS 配置后，由于缓存的原因，还是有很多用户会继续访问修改前的IP ，这样的访问会失败，达
不到负载均衡的目的， 并且也影响用户正常使用业务。
(2）扩展性差： DNS 负载均衡的控制权在域名商那里， 无法根据业务特点针对其做更多的定制化功能和扩展特性。
(3）分配策略比较简单： DNS 负载均衡支持的算法少：不能区分服务器的差异（不能根据系统与服务的状态来判断负载）；也无法感知后端服务器的
状态。
硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器交换机类似，可以理解为一个用于负载均衡的基础网络设备。目前业界典型的硬件
负载均衡设备有两款： FS和AlO
硬件负载均衡的优缺点如下。
【优点】
( 1 ）功能强大： 全面支持各层级的负载均衡，支持全面的负载均衡算法，支持全局负载均衡。
( 2 ）性能强大： 对比一下，软件负载均衡支持到10 万级井发己经很厉害了，硬件负载均衡可以支持100 万以上的并发。
( 3 ） 稳定性高： 商用硬件负载均衡，经过了良好的严格测试，经过大规模使用， 在稳定性方面高。
( 4 ）支持安全防护： 硬件均衡设备除具备负载均衡功能外，还具备防火墙、防DDOS 攻击等安全功能。
【缺点】
( 1 ）价格昂贵： 最普通的一台FS 就是一台“马6 气好一点的就是“宝马、Q7 ”了。
( 2 ）扩展能力差：硬件设备，可以根据业务进行配置， 但无法进行扩展和定制：
软件负载均衡通过负载均衡软件来实现负载均衡功能， 常见的有Nginx 和LVS ， 其中Nginx是软件的7 层负载均衡， LVS 是Linux 内核的4 层负载均衡。
4 层和7 层的区别就在于协议和灵活性。Nginx 支持HTTP 、E-mail 协议， 而LVS 是4 层负载均衡，和协议无关，几乎所有应用都可以做，例如，聊天、数
据库等。软件和硬件的最主要区别就在于性能，硬件负载均衡性能远远高于软件负载均衡性能。Ngxin 的性能是万级，一般的Linux 服务器上装一个Nginx 大
概能到5 万／每秒： LVS 的性能是十万级，据说可达到80 万／每秒；而自性能是百万级，从200 万／每秒到800 万／每秒都有。当然，软件负载均衡的最大
优势是便易，
DNS 负载均衡用于实现地理级别的负载均衡；硬件负载均衡用于实现集群级别的负载均衡；软件负载均衡用于实现机器级别的负载均衡。
(1）任务平分类： 负载均衡系统将收到的任务平均分配给服务器进行处理，这里的“平均”可以是绝对数量的平均，也可以是比例或权重上的平均。
(2）负载均衡类： 负载均衡系统根据服务器的负载来进行分配，这里的负载井不一定是通常意义上我们说的接数、1/0 使用率、网卡吞吐量等来衡量系统的压力。
(3）性能最优类： 负载均衡系统根据服务器的响应时间来进行任务分配， 优先将新任务分配给响应最快的服务器。
(4) Hash 类：负载均衡系统根据任务中的某些关键信息进行Hash 运算，将相同Hash 值的请求分配到同一台服务器上。常见的有源地址Hash 、
目标地址hash 、session id hash、用户id hash 等。
负载均衡系统将收到的任务平均分配给服务器进行处理，这里的“平均”可以是绝对数量的平均，也可以是比例或权重上的平均。
负载均衡系统根据服务器的负载来进行分配，这里的负载井不一定是通常意义上我们说的"CPU负载",而是系统当前的压力，可以用CPU负载来衡量，也可以用连
接数、I/O 使用率、网卡吞吐量等来衡量系统的压力。
【轮询】
负载均衡系统收到请求后，按照顺序轮流分配到服务器上，轮询是最简单的一个策略，无须关注服务器本身的状态，
例如：
• 某个服务器当前因为触发了程序bug 进入了死循环导致CPU 负载很高，负载均衡系统是不感知的，还是会继续将请求源源不断地发送给它。
• 集群中有新的机器是3 2 核的，老的机器是1 6 核的，负载均衡系统也是不关注的，新老机器分配的任务数是一样的。
需要注意的是负载均衡系统无须关注“服务器本身状态”，这里的关键词是“本身”。也就是说，只要服务器在运行，运行状态是不关注的，但如果服务器直接
岩机了，或者服务器和负载均衡系统断连了，则负载均衡系统是能够感知的，也需要做出相应的处理。
例如：
将服务器从可分配服务器列表中删除，否则就会出现服务器都岩机了，任务还不断地分配给它，这明显是不合理的。
【加权轮询】
负载均衡系统根据服务器权重进行任务分配，这里的权重一般是根据硬件配置进行静态配置的，采用动态的方式计算会更加契合业务，但复杂度也会更高。
加权轮询是轮询的一种特殊形式，其主要目的就是为了解决不同服务器处理能力有差异的问题
例如：
集群中有新的机器是32 核的，老的机器是16 核的，那么理论上我们可以假设新机器的处理能力是老机器的2 倍，负载均衡系统就可以按照2 : 1 的比例
分配更多的任务给新机器，从而充分利用新机器的性能。
加权轮询解决了轮询算法中无法根据服务器的配置差异进行任务分配的问题，但同样存在无法根据服务器的状态差异进行任务分配的问题。
【负载最低优先】
负载均衡系统将任务分配给当前负载最低的服务器，这里的负载根据不同的任务类型和业务场景，可以用不同的指标来衡量。
负载最低优先的算法解决了轮询算法中无法感知服务器状态的问题, 负载最低优先类算法是站在服务器的角度来进行分配的
例如：
• LVS 这种4 层网络负载均衡设备，可以以“连接数”来判断服务器的状态，服务器连接数越大，表明服务器压力越大。
• Nginx 这种7 层网络负载系统，可以以“ HTTP 请求数”来判断服务器状态CNginx 内置的负载均衡算法不支持这种方式，需要进行扩展）。
• 如果我们自己开发负载均衡系统，可以根据业务特点来选择指标衡量系统压力。如果是CPU 密集型，可以以“ CPU 负载”来衡量系统压力：如果是I/O
密集型，则可以以“IIO负载”来衡量系统压力。
负载最低优先算法基本上能够比较完美地解决轮询算法的缺点，因为采用这种算法后，负载均衡系统需要感知服务器当前的运行状态。当然，其代价是复杂度
大幅上升
例如：
• 最少连接数优先的算法要求负载均衡系统统计每个服务器当前建立的连接，其应用场景仅限于负载均衡接收的任何连接请求都会转发给服务器进行处理，
否则如果负载均衡系统和服务器之间是固定的连接池方式，就不适合采取这种算法。例如， LVS 可以采取这种算法进行负载均衡，而一个通过连接池的方
式连接MySQ L 集群的负载均衡系统就不适合采取这种算法进行负载均衡。
• CPU 负载最低优先的算法要求负载均衡系统以某种方式收集每个服务器的CPU 负载，而且要确定是以l 分钟的负载为标准，还是以15 分钟的负载为标准
不存在l 分钟肯定比1 5 分钟要好或差。不同业务最优的时间间隔是不一样的，时间间隔太短容易造成频繁波动，时间间隔太长又可能造成峰值来临时
响应缓慢。
负载最低优先算法如果本身没有设计好，或者不适合业务的运行特点，算法本身就可能成为性能的瓶颈，或者引发很多莫名其妙的问题。所以负载最低
优先算法虽然效果看起来很美好， 但实际上真正应用的场景反而没有轮询（包括加权轮询）那么多。
性能最优优先类算法则是站在客户端的角度来进行分配的，优先将任务分配给处理速度最快的服务器，通过这种方式达到最快响应客户端的目的。
和负载最低优先类算法类似，性能最优优先类算法本质上也是感知了服务器的状态，只是通过响应时间这个外部标准来衡量服务器状态而己。因此性能最优优先类
算法存在的问题和负载最低优先类算法类似，复杂度都很高，主要体现在：
• 负载均衡系统需要收集和分析每个服务器每个任务的响应时间， 在大量任务处理的场景下，这种收集和统计本身也会消耗较多的性能。
• 为了减少这种统计上的消耗，可以采取采样的方式来统计，即不统计所有任务的响应时间，而是抽样统计部分任务的响应时间来估算整体任务的响应时间。采样
统计虽然能够减少性能消耗，但使得复杂度进一步上升， 因为要确定合适的采样率，来样率太低会导致结果不准确，采样率太高会导致性能消耗较大，找到合
适的来样率也是一件复杂的事情。无论全部统计，还是采样统计，都需要选择合适的周期： 是10 秒内性能最优，还是1分钟内性能最优，还是5 分钟内性能
最优……没有放之四海而皆准的周期，需要根据实际业务进行判断和选择， 这也是一件比较复杂的事情，甚至出现系统上线后需要不断地调优才能达到最优设计。
负载均衡系统根据任务中的某些关键信息进行Hash 运算，将相同Hash 值的请求分配到同一台服务器上，这样做的目的主要是为了满足特定的业务需求。
• 源地址Hash
将来源于同一个源IP 地址的任务分配给同一个服务器进行处理，适合于存在事务、会话的业务。例如，当我们通过浏览器登录网上银行时，会生成一个会
话信息，这个会话是临时的， 关闭浏览器后就失效。网上银行后台无须持久化会话信息，只需要在某台服务器上临时保存这个会话就可以了，但需要保证
用户在会话存在期间，每次都能访问到同一个服务器，这种业务场景就可以用源地址Hash 来实现。
• ID Hash
将某个ID 标识的业务分配到同一个服务器中进行处理，这里的ID 一般是临时性数据的ID （例如， session id ） 。例如，上述的网上银行登录的例
子，用session id hash 同样可以实现同一个会话期间，用户每次都是访问到同一台服务器的目的。
- 马哥Linux教程-2019全新LVS负载均衡实战
- Linux下nginx的安装使用+负载均衡+集群搭建
- 负载均衡，LVS\keepalived\haproxy实战案例讲解
- LVS+Keepalived+Nginx负载均衡搭建测试
- 实用负载均衡技术网站性能优化攻略.pdf
- 快速理解高性能HTTP服务端的负载均衡技术原理
- 如何打造应对超大流量的高性能负载均衡
- 一分钟了解负载均衡的一切
- lvs为何不能完全替代DNS轮询
- 如何实施异构服务器的负载均衡及过载保护