Java教程

最全负载均衡:算法、实现、亿级负载解决方案详解

本文主要是介绍最全负载均衡:算法、实现、亿级负载解决方案详解,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

01 背景

面对大量用户访问、高并发请求,单机网站可以从软硬件两个方面寻求解决方法:

1、硬件方面:可以使用高性能的服务器、大型数据库,存储设备,高性能Web服务器;

2、软件方面:采用高效率的编程语言(比如Go,Erlang,Scala)等。

但是,当单机容量达到极限时,我们需要考虑业务拆分和分布式部署,来解决大型网站访问量大,并发量高,海量数据的问题。即需要从架构方面寻求解决方案。

02 概述

负载均衡(Load Balance),意思是将负载(如前端的访问请求)进行平衡、(通过负载均衡算法)分摊到多个操作单元(服务器,中间件)上进行执行。是解决高性能,单点故障(高可用),扩展性(水平伸缩)的终极解决方案。可以理解为,负载均衡是高可用和高并发共同使用的一种技术。

负载均衡的作用:

1、增加吞吐量,解决并发压力(高性能);

2、提供故障转移(高可用);

3、通过添加或减少服务器数量,提供网站伸缩性(扩展性);

4、安全防护(负载均衡设备上做一些过滤,黑白名单等处理)。

03 原理

系统的扩展可分为纵向(垂直)扩展和横向(水平)扩展。

纵向扩展,是从单机的角度通过增加硬件处理能力,比如CPU处理能力,内存容量,磁盘等方面,实现服务器处理能力的提升,不能满足大型分布式系统(网站),大流量,高并发,海量数据的问题。因此需要采用横向扩展的方式,通过添加机器来满足大型网站服务的处理能力。比如:一台机器不能满足,则增加两台或者多台机器,共同承担访问压力。

典型负载均衡架构如下:

软件负载解决的两个核心问题是:选谁、转发。

04 分类

4.1 按照软硬件

硬件负载均衡

通过F5、A10、Citrix Netscaler等硬件实现负载均衡。

软件负载均衡

通过LVS、Nginx、HAProxy等软件实现负载均衡。

4.2 按照实现技术

根据实现技术不同,可分为DNS负载均衡,HTTP负载均衡,IP负载均衡,链路层负载均衡等。

DNS负载均衡

最早的负载均衡技术,利用域名解析实现负载均衡,在DNS服务器,配置多个A记录,这些A记录对应的服务器构成集群。大型网站总是部分使用DNS解析,作为第一级负载均衡。

优点:

1、使用简单:负载均衡工作交给DNS服务器处理,不需要专门的服务器维护;

2、提高性能:可以支持基于地址的域名解析,解析成距离用户最近的服务器地址,可以加快访问速度。

缺点:

1、可用性差:新增/修改DNS后,解析时间较长;

2、扩展性低:DNS负载均衡的控制权在域名商,扩展性有限。

实践建议:将DNS作为第一级负载均衡。

IP负载均衡

IP负载均衡,在网络层通过修改请求目标地址进行负载均衡。

优点:

在内核进程完成数据分发,比在应用层分发性能更好。

缺点:

所有请求响应都需要经过负载均衡服务器,集群最大吞吐量受限于负载均衡服务器网卡带宽。

链路层负载均衡

在通信协议的数据链路层修改mac地址,进行负载均衡。

数据分发时,不修改ip地址,指修改目标mac地址,配置真实物理服务器集群所有机器虚拟ip和负载均衡服务器ip地址一致,达到不修改数据包的源地址和目标地址,进行数据分发的目的。

优点:性能好。

缺点:配置复杂。

实践建议:直接路由(DR)模式最常用。

混合型负载均衡

由于多个服务器群内硬件设备、规模、提供服务等差异,可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务,从而达到最佳的性能,将这种方式称之为混合型负载均衡。

4.3 按照OSI层次

二层负载均衡

负载均衡服务器对外依然提供一个 VIP(浮动IP),集群中不同的机器采用相同IP地址,但机器的MAC地址不一样。当负载均衡服务器接受到请求之后,通过改写报文的目标MAC地址的方式将请求转发到目标机器实现负载均衡。

三层负载均衡

负载均衡服务器对外依然提供一个VIP,但集群中不同的机器采用不同的IP地址。当负载均衡服务器接受到请求之后,根据不同的负载均衡算法,通过IP将请求转发至不同的真实服务器。

四层负载均衡

四层负载均衡服务器在接受到客户端请求后,通过修改数据包的地址信息(IP+端口号)将流量转发到应用服务器。

七层负载均衡

七层负载均衡工作在OSI模型的应用层,应用层协议较多,常用HTTP、DNS 等。七层负载就可以基于这些协议来负载。比如同一个Web服务器的负载均衡,除了根据IP加端口进行负载外,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。

05 负载均衡算法

负载均衡服务器在决定将请求转发到具体哪台真实服务器时,是通过负载均衡算法来实现的。负载均衡算法可以分为两类:静态负载均衡算法和动态负载均衡算法。

静态负载均衡算法包括:轮询、比率、优先权。

动态负载均衡算法包括:最少连接数、最快响应速度、观察方法、预测法、动态性能分配、动态服务器补充、服务质量、服务类型、规则模式。

5.1 轮询

轮询(Round Robin):顺序循环将请求一次顺序循环地连接每个服务器。以轮询的方式依次请求调度不同的服务器;实现时,一般为服务器带上权重。

优点:服务器请求数目相同;实现简单、高效;易水平扩展。

缺点:服务器压力不一样,不适合服务器配置不同的情况;请求到目的结点的不确定,造成其无法适用于有写操作的场景。

应用场景:数据库或应用服务层中只有读的场景。

5.2 比率(Ratio)

给每个服务器分配一个加权值为比例,根椐这个比例,把用户的请求分配到每个服务器。

5.3 优先权(Priority)

给所有服务器分组,给每个组定义优先权。当最高优先级中所有服务器出现故障,将请求送给次优先级的服务器组。这种方式,实际为用户提供一种热备份的方式。

5.4 最少连接

将请求分配到连接数最少的服务器(目前处理请求最少的服务器)。

优点:根据服务器当前的请求处理情况,动态分配;

缺点:算法实现相对复杂,需要监控服务器请求连接数;

5.5 最快模式(Fastest)

传递连接给那些响应最快的服务器。

5.6 观察模式(Observed)

连接数目和响应时间这两项的最佳平衡为依据为新的请求选择服务器。

5.7 预测模式(Predictive)

利用收集到的服务器当前的性能指标,进行预测分析,选择一台服务器在下一个时间片内,其性能将达到最佳的服务器相应用户的请求。

5.8 动态性能分配(Dynamic Ratio-APM)

根据收集到的应用程序和应用服务器的各项性能参数,动态调整流量分配。

5.9 动态服务器补充(Dynamic Server Act)

当主服务器群中因故障导致数量减少时,动态地将备份服务器补充至主服务器群。

5.10 服务质量(QoS)

按不同的优先级对数据流进行分配。

5.11 服务类型(ToS)

按不同的服务类型(在 Type of Field 中标识)负载均衡对数据流进行分配。

5.12 规则模式

针对不同的数据流设置导向规则,用户可自行设置。

06 负载均衡方案

6.1 硬件方案

采用硬件的方式实现负载均衡,一般是单独的负载均衡服务器,价格昂贵,常用的有:F5、A10、Citrix Netscaler。

优点:

1、硬件负载均衡稳定性更强,双机或集群的效果更佳,可以应对高并发、高吞吐的网络环境中。

2、在策略配置方面,可以实现深度的健康检查方法,而不是简单的ping或tcp的方式,而是可以针对业务层进行健康检查,整体的策略调度更灵活、配置更方便,在七层负载方面更具优势。

缺点:

1、价格昂贵;

2、扩展能力差,无法进行扩展和定制;

3、调试和维护比较麻烦,需要专业人员。

选择:

核心系统必须使用硬件负载均衡设备;

测试系统和一般系统可以使用软件负载均衡设备。

6.2 软件方案

硬件负载均衡价格昂贵,在实际应用中远不如软件负载均衡普遍。常用的软件负载均衡软件有Nginx、LVS、HaProxy、ats、perlbal、pound等。

Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件。

对比:

LVS:是基于四层的转发(只能做端口转发,不能做基于URL、目录的转发)

HAproxy:是基于四层和七层的转发,是专业的代理服务器

Nginx:是WEB服务器,缓存服务器,又是反向代理服务器,可以做七层的转发

选择:

1、HAproxy和Nginx可做七层转发,URL和目录转发都可以;

2、中小型企业推荐使用HAproxy(配置简单);

3、在很大并发量的时候选择LVS。

07 网络分层负载均衡架构

互联网领域对于负载均衡的架构是随着网站规模提升不断演进的,大致分为如下几个阶段:

第一阶段:利用Nginx或HAProxy进行单点的负载均衡,该阶段服务器刚从单机向集群转变,需要在七层做转发。

第二阶段:随着网络规模扩大,Nginx单点瓶颈突出,这时使用LVS或者商用Array就是首要选择,Nginx此时就作为LVS或者Array的节点来使用,具体LVS或Array的是选择是根据公司规模和预算来选择。

第三阶段:这时网络服务已经成为主流产品,此时随着公司知名度也进一步扩展,相关人才的能力以及数量也随之提升,这时无论从开发适合自身产品的定制,以及降低成本来讲开源的LVS,已经成为首选,这时LVS会成为主流。

常见互联网分布式架构可分为用户层、反向代理层、Web站点层、业务服务层、数据存储层。互联网分层架构:

每层之间交互都有相应的负载均衡方案:

客户端层->反向代理层:DNS轮询。

反向代理层->Web站点层:Ngnix(均衡策略:请求轮询/最少连接路由/IP哈希)。

Web站点层->业务服务层:连接池。

业务服务层->数据存储层:数据分片,读写分离。

这篇关于最全负载均衡:算法、实现、亿级负载解决方案详解的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!