软负载硬负载,这些负载均衡知识你都会了吗?
Posted 侠梦的开发笔记
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软负载硬负载,这些负载均衡知识你都会了吗?相关的知识,希望对你有一定的参考价值。
什么是负载均衡?
生活案列
技术领域
负载均衡的种类
-
配置简单,无成本费用 -
将负载均衡的工作交给了DNS服务器,省去了管理的麻烦。
-
记录的添加与修改是需要一定时间才能够生效的(因为DNS缓存了A记录)。一旦有一台服务器坏了需要下线,即使修改了A记录,要使其生效也需要较长的时间,这段时间,DNS仍然会将域名解析到已下线的服务器上,最终导致用户访问失败。 -
不能按需分配负载,DNS并不知道各服务器的真实负载情况,所以负载效果不是很好
硬件负载均衡
-
功能强大:全面支持各层级的负载均衡,支持各种负载均衡算法,支持全局负载均衡。 -
性能好:一般软件负载均衡能支撑10w+并发已经很不错了,但是硬件的负载均衡却可以支持100w+以上的并发。 -
高稳定性:因为是商业品,所以经过了良好严格的测试,经过大规模的使用,所以稳定非常高。 -
安全性高:硬件负载均衡设备除了能处理负载均衡以外,还具有防火墙、防DDOS攻击等效果。
-
价格昂贵:我记得之前银行购买F5花了上百万,据说还有更贵的,所以价格可想而知。 -
扩展性不好:硬件设备可以根据业务进行配置,但无法进行扩展和定制化。
软件负载均衡
-
nginx由C编写,同样的web服务器,占用的资源和内存低性能高。 -
当启动nginx服务器,会生成一个master进程,master进程会fork出多个worker进程,由worker线程处理客户端的请求。 -
nginx支持高并发,每个worker子进程是独立平等的,当有客户端请求时,worker进程公平竞争,抢到的worker进程会把请求提交给后端服务器,当后端服务器没有及时响应时,此worker进程会继续接收下一个request,当上一个请求有响应后会触发事件,此worker进程继续之前的执行,知道响应结束。一个request不会被两个worker进程执行。 -
nginx支持反向代理(用户有感知的访问叫正向代理如使用vpn访问youtube,用户无感知访问叫反向代理如负载均衡),支持7层负载均衡(拓展负载均衡的好处)。 -
nginx是异步非阻塞型处理请求(第三点印证),采用的epollandqueue模式,apache是阻塞型处理请求。 -
nginx处理静态文件速度快(原因: -
nginx高度模块化,配置简单。 -
nginx是单进程多线程)。
-
对比apache不稳定,由于是单进程多线程,进程死掉会影响很多用户。
负载均衡有什么用?
-
**「流量分发」**负载均衡能对多台主机流量进行分发,提高用户系统的业务处理能力,提升服务可用性 -
**「会话保持」**在会话周期内,会话保持可使来自同一IP或网段的请求被分发到同一台后端服务器上。 -
**「健康检查」**支持自定义健康检查方式和频率,可定时检查后端主机运行状态,提供故障转移,实现高可用; -
**「负载均衡」**解决并发压力,提高应用处理性能(增加吞吐量,加强网络处理能力); -
提高扩展性通过添加或减少服务器数量,提供网站伸缩性(扩展性); -
提高安全性安全防护,在负载均衡器上做一些过滤,黑白名单、防盗链等处理;
常用负载均衡算法
轮训
加权轮训
负载最低优先
-
LVS这种4层网络负载均衡设备,可以以连接数来判断服务器的状态,服务器连接数量越大,表明服务器压力就越大。 -
Nginx这种7层网络负载均衡系统,可以以HTTP请求数量判断服务器的状态(Nginx内置的负载均衡算法不支持这种方式,需要自行进行扩展)。 -
如果我们是自己研发负载均衡系统,可以根据业务特点来选择衡量系统压力的指标。如果CPU是密集型,可以以CPU负载来衡量系统的压力;如果是IO密集型,则可以以IO负载来衡量系统压力。
-
最少链接数优先的算法要求负载系统统计每个服务器当前简历的链接,其应用场景仅限于负载均衡接收的任何请求都会转发给服务器进行处理,否则如果负载均衡系统和服务之间是固定的连接池方式,就不适合采取这种算法。LVS可以采取这种算法进行负载均衡,而一个通过连接池的方式链接数据库mysql集群的负载均衡系统就不适合采取这种算法进行负载均衡了。 -
CPU负载均衡最低优先的算法要求负载均衡系统以某种方式收集每个服务器的CPU的具体负载情况,同时要确定是以一分钟的负载标准,还是以10分钟、15分钟的负载标准,不存在1分钟肯定比15分钟的好或差。不同业务最优的时间间隔也是不一样的,时间间隔太短容易造成频繁波动,时间太长可能造成峰值来临时响应缓慢。
性能最优
-
负载均衡系统需要收集每次请求的响应时间,如果在大量请求处理的场景下,这种收集再加上响应时间的统计本身也会消耗系统的性能。 -
为了减少这种统计上的消耗,可以采取采样的方式进行统计,即就是不用很完全的去统计所有服务器的所有请求时间,而是抽样统计部分任务的响应时间来估算整体请求所花的响应时间。采样统计虽然能减轻性能的消耗,但使得实现的复杂度增加了很多,因为要确定合适的采样率,采样率太低会导致数据的正确性,采样率高同样会造成性能的消耗,要找到一个合适的采样率的复杂度也是可想而知的。 -
无论全部统计,还是采样统计,都需要选择合适的周期,是30秒性能最优还是1分钟最优?目前是没有标准的周期,都是需要具体业务场景进行决策,是不是感觉到了其复杂性,尤其是线上系统需要不断的调试,然后找出相对合适的标准。
Hash类
-
源地址Hash:将来源于同一个IP地址的请求分配给同一个服务器进行处理,适合于存在事务、会话的业务。例如:当我们通过浏览器登录网上银行时,会生成一个会话信息,这个会话是临时的,关闭浏览器后就会失效。网上银行后台无须持久会话信息,只需要在某台服务器临时保留这个会话就可以了,但需要保证用户在会话存在期间,每次请求都能访问在同一个服务器,这种业务场景就是通过源地址hash来实现的。 -
ID hash :将某个ID表示的业务分配到同一台服务器上进行处理,比如:userId session id。上述的网上银行登录的例子,用session id hash可以实现同一个会话期间,用户每次都是访问同一台服务器上的目的。
负载均衡算法应用
-
Random LoadBalance(随机算法,默认) -
RoundRobin LoadBalance(权重轮训算法) -
LeastAction LoadBalance(最少活跃调用数算法) -
ConsistentHash LoadBalance(一致性Hash法)
upstream bakend {
server 192.168.0.14 weight=10;
server 192.168.0.15 weight=10;
}
upstream bakend {
server 192.168.0.14:88;
server 192.168.0.15:80;
upstream backend {
server server1;
server server2;
总结
都收藏了,就点个「在看」支持一下吧!
点下在看,你最好看
以上是关于软负载硬负载,这些负载均衡知识你都会了吗?的主要内容,如果未能解决你的问题,请参考以下文章