负载均衡在分布式架构中是怎么玩起来的？

什么是负载均衡（Load balancing）

 

在网站创立初期，咱们通常都使用单台机器对台提供集中式服务，但随着业务量愈来愈大，不管性能仍是稳定性上都有了更大的挑战。这时候咱们就会想到经过扩容的方式来提供更好的服务。咱们通常会把多台机器组成一个集群对外提供服务。然而，咱们的网站对外提供的访问入口都是一个的，好比www.taobao.com。那么当用户在浏览器输入www.taobao.com的时候如何将用户的请求分发到集群中不一样的机器上呢，这就是负载均衡在作的事情。

 

当前大多数的互联网系统都使用了服务器集群技术，集群即将相同服务部署在多台服务器上构成一个集群总体对外提供服务，这些集群能够是Web应用服务器集群，也能够是数据库服务器集群，还能够是分布式缓存服务器集群等。

 

在实际应用中，在Web服务器集群以前总会有一台负载均衡服务器，负载均衡设备的任务就是做为Web服务器流量的入口，挑选最合适的一台Web服务器，将客户端的请求转发给它处理，实现客户端到真实服务端的透明转发。最近几年很火的「云计算」以及分布式架构，本质上也是将后端服务器做为计算资源、存储资源，由某台管理服务器封装成一个服务对外提供，客户端不须要关心真正提供服务的是哪台机器，在它看来，就好像它面对的是一台拥有近乎无限能力的服务器，而本质上，真正提供服务的是后端的集群。

软件负载解决的两个核心问题是：选谁、转发，其中最著名的是LVS（Linux Virtual Server）。

 

 

一个典型的互联网应用的拓扑结构是这样的：

 

 

负载均衡分类

 

如今咱们知道，负载均衡就是一种计算机网络技术，用来在多个计算机（计算机集群）、网络链接、CPU、磁碟驱动器或其它资源中分配负载，以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。那么，这种计算机技术的实现方式有多种。大体能够分为如下几种，其中最经常使用的是四层和七层负载均衡：

 

二层负载均衡

 

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

 

三层负载均衡

 

和二层负载均衡相似，负载均衡服务器对外依然提供一个VIP（虚IP），但集群中不一样的机器采用不一样的IP地址。当负载均衡服务器接受到请求以后，根据不一样的负载均衡算法，经过IP将请求转发至不一样的真实服务器。

 

四层负载均衡

 

四层负载均衡工做在OSI模型的传输层，因为在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP之外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，之后经过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。

 

七层负载均衡

 

七层负载均衡工做在OSI模型的应用层，应用层协议较多，经常使用http、radius、DNS等。七层负载就能够基于这些协议来负载。这些应用层协议中会包含不少有意义的内容。好比同一个Web服务器的负载均衡，除了根据IP加端口进行负载外，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。

 

图：四层和七层负载均衡

 

对于通常的应用来讲，有了Nginx就够了。Nginx能够用于七层负载均衡。可是对于一些大的网站，通常会采用DNS+四层负载+七层负载的方式进行多层次负载均衡。

 

 

 

经常使用负载均衡工具

 

硬件负载均衡性能优越，功能全面，但价格昂贵，通常适合初期或者土豪级公司长期使用。所以软件负载均衡在互联网领域大量使用。经常使用的软件负载均衡软件有Nginx、LVS、HaProxy等。

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

 

1、 LVS

 

LVS（Linux Virtual Server），也就是Linux虚拟服务器，是一个由章文嵩博士发起的自由软件项目。使用LVS技术要达到的目标是：经过LVS提供的负载均衡技术和Linux操做系统实现一个高性能、高可用的服务器群集，它具备良好可靠性、可扩展性和可操做性。从而以低廉的成本实现最优的服务性能。

 

LVS主要用来作四层负载均衡。

 

LVS架构

LVS架设的服务器集群系统由三个部分组成：最前端的负载均衡层（Loader Balancer），中间的服务器群组层，用Server Array表示，最底层的数据共享存储层，用Shared Storage表示。在用户看来全部的应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。

 

 

LVS的各个层次的详细介绍：

 

Load Balancer层：位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要做用相似于一个路由器，它含有完成LVS功能所设定的路由表，经过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康情况。在Real Server不可用时把它从LVS路由表中剔除，恢复时从新加入。

 

Server Array层：由一组实际运行应用服务的机器组成，Real Server能够是Web服务器、Mail服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每一个Real Server之间经过高速的LAN或分布在各地的WAN相链接。在实际的应用中，Director Server也能够同时兼任Real Server的角色。

 

Shared Storage层：是为全部Real Server提供共享存储空间和内容一致性的存储区域，在物理上通常由磁盘阵列设备组成，为了提供内容的一致性，通常能够经过NFS网络文件系统共享数 据，但NFS在繁忙的业务系统中，性能并非很好，此时能够采用集群文件系统，例如Red hat的GFS文件系统、Oracle提供的OCFS2文件系统等。

 

从整个LVS结构能够看出，Director Server是整个LVS的核心，目前用于Director Server的操做系统只能是Linux和FreeBSD，Linux2.6内核不用任何设置就能够支持LVS功能，而FreeBSD做为 Director Server的应用还不是不少，性能也不是很好。对于Real Server，几乎能够是全部的系统平台，Linux、windows、Solaris、AIX、BSD系列都能很好地支持。

 

二、Nginx

 

 

Nginx（发音同engine x）是一个网页服务器，它能反向代理HTTP、HTTPS,、SMTP、POP三、IMAP的协议连接，以及一个负载均衡器和一个HTTP缓存。

 

Nginx主要用来作七层负载均衡。

并发性能：官方支持每秒5万并发，实际国内通常到每秒2万并发，有优化到每秒10万并发的。具体性能看应用场景。

 

特色：

• 模块化设计：良好的扩展性，能够经过模块方式进行功能扩展。

• 高可靠性：主控进程和worker是同步实现的，一个worker出现问题，会马上启动另外一个worker。

• 内存消耗低：一万个长链接（keep-alive）,仅消耗2.5MB内存。

• 支持热部署：不用中止服务器，实现更新配置文件，更换日志文件、更新服务器程序版本。

• 并发能力强：官方数据每秒支持5万并发；

• 功能丰富：优秀的反向代理功能和灵活的负载均衡策略

 

Nginx的基本工做模式

 

 

 

一个master进程，生成一个或者多个worker进程。但这里master是使用root身份启动的，由于nginx要工做在80端口。而只有管理员才有权限启动小于低于1023的端口。master主要是负责的做用只是启动worker，加载配置文件，负责系统的平滑升级。其它的工做是交给worker。那当worker被启动以后，也只是负责一些web最简单的工做，而其它的工做都是由worker中调用的模块来实现的。

模块之间是以流水线的方式实现功能的。流水线，指的是一个用户请求，由多个模块组合各自的功能依次实现完成的。好比：第一个模块只负责分析请求首部，第二个模块只负责查找数据，第三个模块只负责压缩数据，依次完成各自工做。来实现整个工做的完成。

它们是如何实现热部署的呢？是这样的，咱们前面说master不负责具体的工做，而是调用worker工做，它只是负责读取配置文件，所以当一个模块修改或者配置文件发生变化，是由master进行读取，所以此时不会影响到worker工做。在master进行读取配置文件以后，不会当即把修改的配置文件告知worker。而是让被修改的worker继续使用老的配置文件工做，当worker工做完毕以后，直接当掉这个子进程，更换新的子进程，使用新的规则。

 

3、HAProxy

 

HAProxy也是使用较多的一款负载均衡软件。HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，是免费、快速而且可靠的一种解决方案。特别适用于那些负载特大的web站点。运行模式使得它能够很简单安全的整合到当前的架构中，同时能够保护你的web服务器不被暴露到网络上。

HAProxy是一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于TCP和HTTP的应用程序代理。

 

Haproxy主要用来作七层负载均衡。

 

常见负载均衡算法

 

上面介绍负载均衡技术的时候提到过，负载均衡服务器在决定将请求转发到具体哪台真实服务器时，是经过负载均衡算法来实现的。负载均衡算法能够分为两类：静态负载均衡算法和动态负载均衡算法。

 

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

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

 

轮询（Round Robin）：顺序循环将请求一次顺序循环地链接每一个服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。

以轮询的方式依次请求调度不一样的服务器； 实现时，通常为服务器带上权重；这样有两个好处：

 

• 针对服务器的性能差别可分配不一样的负载；

• 当须要将某个结点剔除时，只须要将其权重设置为0便可；
  
  

优势：实现简单、高效；易水平扩展

缺点：请求到目的结点的不肯定，形成其没法适用于有写的场景（缓存，数据库写）

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

 

随机方式：请求随机分布到各个结点；在数据足够大的场景能达到一个均衡分布；

优势：实现简单、易水平扩展

缺点：同Round Robin，没法用于有写的场景

应用场景：数据库负载均衡，也是只有读的场景

 

哈希方式：根据key来计算须要落在的结点上，能够保证一个同一个键必定落在相同的服务器上；

优势：相同key必定落在同一个结点上，这样就可用于有写有读的缓存场景

缺点：在某个结点故障后，会致使哈希键从新分布，形成命中率大幅度降低

解决：一致性哈希 or 使用keepalived保证任何一个结点的高可用性，故障后会有其它结点顶上来

应用场景：缓存，有读有写

 

一致性哈希：在服务器一个结点出现故障时，受影响的只有这个结点上的key，最大程度的保证命中率； 如twemproxy中的ketama方案； 生产实现中还能够规划指定子key哈希，从而保证局部类似特征的键能分布在同一个服务器上；

优势：结点故障后命中率降低有限

应用场景：缓存

 

根据键的范围来负载：根据键的范围来负载，前1亿个键都存放到第一个服务器，1~2亿在第二个结点。

优势：水平扩展容易，存储不够用时，加服务器存放后续新增数据

缺点：负载不均；数据库的分布不均衡；

（数据有冷热区分，通常最近注册的用户更加活跃，这样形成后续的服务器很是繁忙，而前期的结点空闲不少）

适用场景：数据库分片负载均衡

 

根据键对服务器结点数取模来负载：根据键对服务器结点数取模来负载；好比有4台服务器，key取模为0的落在第一个结点，1落在第二个结点上。

优势：数据冷热分布均衡，数据库结点负载均衡分布；

缺点：水平扩展较难；

适用场景：数据库分片负载均衡

 

纯动态结点负载均衡：根据CPU、IO、网络的处理能力来决策接下来的请求如何调度。

优势：充分利用服务器的资源，保证个结点上负载处理均衡

缺点：实现起来复杂，真实使用较少

 

不用主动负载均衡：使用消息队列转为异步模型，将负载均衡的问题消灭；负载均衡是一种推模型，一直向你发数据，那么将全部的用户请求发到消息队列中，全部的下游结点谁空闲，谁上来取数据处理；转为拉模型以后，消除了对下行结点负载的问题。

优势：经过消息队列的缓冲，保护后端系统，请求剧增时不会冲垮后端服务器；水平扩展容易，加入新结点后，直接取queue便可；
缺点：不具备实时性；

应用场景：不须要实时返回的场景；

好比，12036下订单后，马上返回提示信息：您的订单进去排队了...等处理完毕后，再异步通知；

 

比率（Ratio）：给每一个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每一个服务器。当其中某个服务器发生第2到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

 

优先权（Priority）：给全部服务器分组，给每一个组定义优先权，BIG-IP 用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的请求）；当最高优先级中全部服务器出现故障，BIG-IP 才将请求送给次优先级的服务器组。这种方式，实际为用户提供一种热备份的方式。

 

最少的链接方式（Least Connection）：传递新的链接给那些进行最少链接处理的服务器。当其中某个服务器发生第2到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

 

最快模式（Fastest）：传递链接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

 

观察模式（Observed）：链接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。

 

预测模式（Predictive）：BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)

 

动态性能分配(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。

 

动态服务器补充(Dynamic Server Act.):当主服务器群中因故障致使数量减小时，动态地将备份服务器补充至主服务器群。

 

服务质量(QoS）:按不一样的优先级对数据流进行分配。

 

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

 

规则模式：针对不一样的数据流设置导向规则，用户可自行。

 

负载均衡的几种算法Java实现代码

 

• • 轮询

   

   

  • 加权随机负载均衡算法

   

   

  • 随机负载均衡算法

   

   

  • 负载均衡 ip_hash算法.