负载均衡器(负载均衡器的软件有哪些)

1.软文推荐

2.软文推荐

3.软文推荐

服务端负载均衡：在客户端和服务端中间使用代理，lvs  和 nginx。

硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备的时候，该设备按某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端端地址，然后进行转发。

客户端负载均衡：根据自己的情况做负载。Ribbon。

客户端负载均衡和服务端负载均衡最大的区别在于 服务端地址列表的存储位置，以及负载算法在哪里。

2、Spring Cloud的负载均衡机制的实现

Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Ribbon实现客户端的负载均衡，负载均衡器提供很多对http和tcp的行为控制。Spring cloud Feign已经集成Ribbon，所以注解@FeignClient的类，默认实现了ribbon的功能。

Ribbon主要包括如下功能

1.支持通过DNS和IP和服务端通信

2.可以根据算法从多个服务中选取一个服务进行访问

3.通过将客户端和服务器分成几个区域（zone）来建立客户端和服务器之间的关系。客户端尽量访问和自己在相同区域(zone)的服务，减少服务的延迟

4.保留服务器的统计信息，ribbon可以实现用于避免高延迟或频繁访问故障的服务器

5.保留区域(zone)的统计数据，ribbon可以实现避免可能访问失效的区域(zone)

Ribbon负载均衡主要是通过LoadBalancerClient类实现的，而LoadBalancerClient又将具体处理委托给ILoadBalancer处理；

每个服务都有一个ILoadBalancer，ILoadBalancer里面有该服务列表。

每个服务 Map服务名，ILoadBalancer

ILoadBalancer通过配置IRule、IPing等信息，并通过ServerList获取服务器注册列表的信息，默认以每10s的频率想服务列表中每个服务实例发送ping请求，检测服务实例是否存活，最后使用负责均衡策略对ServerListFilter过滤得到最终可用的服务实例列表进行处理，然后交给服务调用器进行调用；

ILoadBalance也是一个接口，提供了3个具体实现，分别是DynamicServerListLoadBalancer、ZoneAwareLoadBalancer和NoOpLoadBalancer；

DynamicServerListLoadBalancer继承自ILoadBalancer基础实现BaseLoadBalancer，在基础的负载均衡功能上增加了运行期间对服务实例动态更新和过滤的功能；

NoOpLoadBalancer没有操作的实现；

ZoneAwareLoadBalancer（ILoadBalancer的默认的实现类是：ZoneAwareLoadBalancer。）则是继承DynamicServerListLoadBalancer，在此基础上增加防止跨区域访问的问题；

首先它会剔除符合这些规则的Zone区域：所属实例数位零的Zone区域；Zone区域内实例等平均负载小于零，或者实例故障率（断路器断开次数／实例数）大于等于阀值（默认为0.99999）。

然后根据Zone区域等实例平均负载计算出最差的Zone区域，这里的最差指的是实例平均负载最高的Zone区域。

如果在上面的过程中没有符合剔除要求的区域，同时实例最大平均负载小于阀值（默认为20%），就直接返回所有Zone区域为可用区域。否则，从最坏Zone区域集合中随机选择一个，将它从可用Zone区域集合中剔除。

 ▪️当获得的可用Zone区域集合不为空，并且个数小于Zone区域总数，就随机选择一个Zone区域。

▪️在确定了某个Zone区域后，则获取了对应Zone区域的服务均衡器，并调用chooseServer来选择具体的服务实例，而在chooseServer中将使用IRule接口的choose函数来选择具体的服务实例。在这里，IRule接口的实现会使用ZoneAvoidanceRule来挑选出具体的服务实例。

服务列表就是客户端负载均衡所使用的(同一注册中心集群)各服务的服务实例列表。Ribbon在实现上支持以下几种服务列表方式

静态服务器列表：通过Ribbon的BaseLoadBalancer所提供的setServerList()方法，初始化时直接进行动态设置指定；

基于配置的服务器列表：需要在项目配置文件中通过服务名称.ribbon.listOfServers进行设置。（如user-service.ribbon.listOfServers=）

基于服务发现的服务器列表：同时使用Ribbon和Eureka时，默认使用该方式，在应用启动时Ribbon就会从Eureka服务器中获取所有注册服务的列表数据，并保持同步。

该组件会对原始服务列表使用一定策略进行过滤返回有效可用的服务器列表给客户端负载均衡器使用。常用服务列表过滤器如下：ZoneAffinityServerListFilter：基于区域感知的方式，实现对服务实例的过滤，仅返回与本身所处区域一直的服务提供者实例列表；ServerListSubsetFilter：该过滤器继承自ZoneAffinityServerListFilter，在进行区域感知过滤后，仅返回一个固定大小的服务列表。默认将返回20个服务实例，可以通过ribbon.ServerListSubsetFilter.size进行设置；

ZonePreferenceServerListFilter：使用Eureka和Ribbon时默认的过滤器。实现通过配置或者Eureka所属区域来过滤出同区域的服务实例列表。

它实现了通过配置或者Eureka实例元数据的所属区域（Zone）来过滤出同区域的服务实例。如下面的源码所示，它的实现非常简单，首先通过父类ZoneAffinityServerListFilter的过滤器来获得“区域感知”的服务实例列表，然后遍历这个结果，取出根据消费者配置预设的区域Zone来进行过滤，如果过滤掉结果是空就直接返回父类获取的结果，如果不为空就返回通过消费者配置的Zone过滤后的结果。

用来检测一个微服务实例是否存活是否有响应，Ribbon通过该组件来判断所持有的服务实例列表中各服务可用情况，如果检测到某服务实例不存在/一定时间未响应，则会从持有服务列表中及时移除。

PingUrl：通过定期访问指定的URL判断；

PingConstant：不做任何处理，只返回一个固定值，用来表示该服务是否可用，默认值为true；

NoOpPing：不做任何处理，直接返回true，表示该服务器可用，默认策略；

DummyPing：直接返回true，但实现了initWithNiwsConfig方法；

NIWSDiscoverPing：根据DiscoveryEnabledServer中InstanceInfo的InstanceStatus属性判断，如果该属性的值为InstanceStatus.UP，则表示服务器可用；

作用就是选择一个最终服务实例地址作为负载均衡处理结果。Ribbon提供的选择策略有随机 (Random)、轮询 (RoundRobin)、一致性哈希 (ConsistentHash)、哈希 (Hash)、加权（Weighted）。

IRule负载均衡策略：通过实现该接口定义自己的负载均衡策略。它的choose方法就是从一堆服务器列表中按规则选出一个服务器。

默认实现：

ZoneAvoidanceRule（区域权衡策略）：复合判断Server所在区域的性能和Server的可用性，轮询选择服务器。

其他规则：

BestAvailableRule（最低并发策略）：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务。逐个找服务，如果断路器打开，则忽略。

RoundRobinRule（轮询策略）：以简单轮询选择一个服务器。按顺序循环选择一个server。

RandomRule（随机策略）：随机选择一个服务器。

AvailabilityFilteringRule（可用过滤策略）：会先过滤掉多次访问故障而处于断路器跳闸状态的服务和过滤并发的连接数量超过阀值得服务，然后对剩余的服务列表安装轮询策略进行访问。

WeightedResponseTimeRule（响应时间加权策略）：据平均响应时间计算所有的服务的权重，响应时间越快服务权重越大，容易被选中的概率就越高。刚启动时，如果统计信息不中，则使用RoundRobinRule(轮询)策略，等统计的信息足够了会自动的切换到WeightedResponseTimeRule。响应时间长，权重低，被选择的概率低。反之，同样道理。此策略综合了各种因素（网络，磁盘，IO等），这些因素直接影响响应时间。

RetryRule（重试策略）：先按照RoundRobinRule(轮询)的策略获取服务，如果获取的服务失败则在指定的时间会进行重试，进行获取可用的服务。如多次获取某个服务失败，就不会再次获取该服务。主要是在一个时间段内，如果选择一个服务不成功，就继续找可用的服务，直到超时。

1. clientName：这是调用ribbon的客户端名称，如果此值为没有配置，则此条属性会作用到所有的客户端。

2. nameSpace：默认值为 “ribbon”

3. propertyName：所有的可用的属性都在com.netflix.client.conf.CommonClientConfigKey。

clientName.nameSpace.NFLoadBalancerClassName=xx

clientName.nameSpace.NFLoadBalancerRuleClassName=xx

clientName.nameSpace.NFLoadBalancerPingClassName=xx

clientName.nameSpace.NIWSServerListClassName=xx

clientName.nameSpace.NIWSServerListFilterClassName=xx

com.netflix.client.config.IClientConfig：Ribbon的客户端配置，默认采用com.netflix.client.config.DefaultClientConfigImpl实现。

com.netflix.loadbalancer.IRule：Ribbon的负载均衡策略，默认采用com.netflix.loadbalancer.ZoneAvoidanceRule实现，该策略能够在多区域环境下选出最佳区域的实例进行访问。

com.netflix.loadbalancer.IPing：Ribbon的实例检查策略，默认采用com.netflix.loadbalancer.NoOpPing实现，该检查策略是一个特殊的实现，实际上它并不会检查实例是否可用，而是始终返回true，默认认为所有服务实例都是可用的。

com.netflix.loadbalancer.ServerList：服务实例清单的维护机制，默认采用com.netflix.loadbalancer.ConfigurationBasedServerList实现。

com.netflix.loadbalancer.ServerListFilter：服务实例清单过滤机制，默认采org.springframework.cloud.netflix.ribbon.ZonePreferenceServerListFilter，该策略能够优先过滤出与请求方处于同区域的服务实例。

com.netflix.loadbalancer.ILoadBalancer：负载均衡器，默认采用com.netflix.loadbalancer.ZoneAwareLoadBalancer实现，它具备了区域感知的能力。

上面的配置是在项目中没有引入spring Cloud Eureka，如果引入了Eureka和Ribbon依赖时，自动化配置会有一些不同。

通过自动化配置的实现，可以轻松的实现客户端的负载均衡。同时，针对一些个性化需求，我们可以方便的替换上面的这些默认实现，只需要在springboot应用中创建对应的实现实例就能覆盖这些默认的配置实现。

@Configuration

public class MyRibbonConfiguration {

    @Bean

    public IRule ribbonRule(){

        return new RandomRule();

    }

}

这样就会使用P使用了RandomRule实例替代了默认的com.netflix.loadbalancer.ZoneAvoidanceRule。

也可以使用@RibbonClient注解实现更细粒度的客户端配置

对于Ribbon的参数通常有二种方式：全局配置以及指定客户端配置

全局配置的方式很简单

只需要使用ribbon.key=value格式进行配置即可。其中，key代表了Ribbon客户端配置的参数名，value则代表了对应参数的值。比如，我们可以想下面这样配置Ribbon的超时时间

ribbon.ConnectTimeout=250

ribbon.ServerListRefreshInterval=2000   ribbon获取服务定时时间

全局配置可以作为默认值进行设置，当指定客户端配置了相应的key的值时，将覆盖全局配置的内容

指定客户端的配置方式

client.ribbon.key=value的格式进行配置.client表示服务名，比如没有服务治理框架的时候（如Eureka），我们需要指定实例清单，可以指定服务名来做详细的配置，

user-service.ribbon.listOfServers=localhost:8080,localhost:8081,localhost:8082

对于Ribbon参数的key以及value类型的定义，可以通过查看com.netflix.client.config.CommonClientConfigKey类。

当在spring Cloud的应用同时引入Spring cloud Ribbon和Spring Cloud Eureka依赖时，会触发Eureka中实现的对Ribbon的自动化配置。这时的serverList的维护机制实现将被com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList的实例所覆盖，该实现会讲服务清单列表交给Eureka的服务治理机制来进行维护。IPing的实现将被com.netflix.niws.loadbalancer.NIWSDiscoveryPing的实例所覆盖，该实例也将实例接口的任务交给了服务治理框架来进行维护。默认情况下，用于获取实例请求的ServerList接口实现将采用Spring Cloud Eureka中封装的org.springframework.cloud.netflix.ribbon.eureka.DomainExtractingServerList，其目的是为了让实例维护策略更加通用，所以将使用物理元数据来进行负载均衡，而不是使用原生的AWS AMI元数据。在与Spring cloud Eureka结合使用的时候，不需要再去指定类似的user-service.ribbon.listOfServers的参数来指定具体的服务实例清单，因为Eureka将会为我们维护所有服务的实例清单，而对于Ribbon的参数配置，我们依然可以采用之前的两种配置方式来实现。

此外，由于spring Cloud Ribbon默认实现了区域亲和策略，所以，可以通过Eureka实例的元数据配置来实现区域化的实例配置方案。比如可以将不同机房的实例配置成不同的区域值，作为跨区域的容器机制实现。而实现也非常简单，只需要服务实例的元数据中增加zone参数来指定自己所在的区域，比如：

eureka.instance.metadataMap.zone=shanghai

在Spring Cloud Ribbon与Spring Cloud Eureka结合的工程中，我们可以通过参数禁用Eureka对Ribbon服务实例的维护实现。这时又需要自己去维护服务实例列表了。

ribbon.eureka.enabled=false.

由于Spring Cloud Eureka实现的服务治理机制强调了cap原理的ap机制（即可用性和可靠性），与zookeeper这类强调cp（一致性，可靠性）服务质量框架最大的区别就是，Eureka为了实现更高的服务可用性，牺牲了一定的一致性，在极端情况下宁愿接受故障实例也不要丢弃"健康"实例。

比如说，当服务注册中心的网络发生故障断开时候，由于所有的服务实例无法维护续约心跳，在强调ap的服务治理中将会把所有服务实例剔除掉，而Eureka则会因为超过85%的实例丢失心跳而触发保护机制，注册中心将会保留此时的所有节点，以实现服务间依然可以进行互相调用的场景，即使其中有部分故障节点，但这样做可以继续保障大多数服务的正常消费。

在Camden版本，整合了spring retry来增强RestTemplate的重试能力，对于我们开发者来说，只需要简单配置，即可完成重试策略。

spring.cloud.loadbalancer.retry.enabled=true

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000

user-service.ribbon.ConnectTimeout=250

user-service.ribbon.ReadTimeout=1000

user-service.ribbon.OkToRetryOnAllOperations=true

user-service.ribbon.MaxAutoRetriesNextServer=2

user-service.ribbon.maxAutoRetries=1

spring.cloud.loadbalancer.retry.enabled:该参数用来开启重试机制，它默认是关闭的。

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds：断路器的超时时间需要大于Ribbon的超时时间，不然不会触发重试。

user-service.ribbon.ConnectTimeout：请求连接超时时间。

user-service.ribbon.ReadTimeout：请求处理的超时时间

user-service.ribbon.OkToRetryOnAllOperations：对所有操作请求都进行重试。

user-service.ribbon.MaxAutoRetriesNextServer：切换实例的重试次数。

user-service.ribbon.maxAutoRetries：对当前实例的重试次数。

根据以上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由maxAutoRetries配置），如果不行，就换一个实例进行访问，如果还是不行，再换一个实例访问（更换次数由MaxAutoRetriesNextServer配置），如果依然不行，返回失败

项目启动的时候会自动的为我们加载LoadBalancerAutoConfiguration自动配置类，该自动配置类初始化条件是要求classpath必须要有RestTemplate这个类，必须要有LoadBalancerClient实现类。

LoadBalancerAutoConfiguration为我们干了二件事，第一件是创建了LoadBalancerInterceptor拦截器bean，用于实现对客户端发起请求时进行拦截，以实现客户端负载均衡。创建了一个

RestTemplateCustomizer的bean，用于给RestTemplate增加LoadBalancerInterceptor拦截器。

每次请求的时候都会执行org.springframework.cloud.client.loadbalancer.LoadBalancerInterceptor的intercept方法，而LoadBalancerInterceptor具有LoadBalancerClient（客户端负载客户端）实例的一个引用，

在拦截器中通过方法获取服务名的请求url（比如），及服务名（比如user-service），然后调用负载均衡客户端的execute方法。

执行负载客户端RibbonLoadBalancerClient（LoadBalancerClient的实现）的execute方法，得到ILoadBalancer（负载均衡器）的实现ZoneAwareLoadBalancer，并且通过调用其chooseServer方法获得服务列表中的一个实例，比如说user-service列表注册到eureka中一个实例。然后向其中的一个具体实例发起请求，得到结果。

Ribbon详解 

Spring cloud系列六 Ribbon的功能概述、主要组件和属性文件配置  

Ribbon的ZoneAwareLoadBalancer  

Ribbon的实际使用

本人有道云笔记中记录的参考文章

文档：04_ribbon 负载均衡.note

链接：;sub=2516B0E6DFEE4786B26D9528AF522928路由负载均衡是什么

问题一：负载均衡和路由器的区别 其实运营商级别的路由器都带有负载均衡的功能。所谓负载均衡，就是指路由器把流量平均转发到几条等价的路由路径上。而双机冗余是ip网络组网的一种业务保护措施，主机down掉后，业务能快速切换到被机上继续工作。

负载均衡是一台路由器自身的事情；双机冗余是多台设备组网方案的事情，两者很大不同。

问题二：路由器的智能负载均衡功能是指什么 智能型负载均衡对于路由器来说非常重要，简单来说是利用多个网络设备通道均衡分担流量。

就像是寺庙一天要挑10桶水，1个尚必需要走10趟，但同时指派10个和尚却只要一趟即可完成工作的道理一样。智能型负载均衡可运用多个网络设备同时工作，达成加速网络信息的处理能力，进而优化网络设备的性能，取代设备必须不停升级或淘汰的命运。目前普遍被运用在网络设备中，如服务器、路由器、交换机等。目前提出的三种不同的智能型负载均衡模式，可较全面的包含各 种网络架构中所应采取措施，三种模式分别是：

模式一：智能型负载均衡

智能型负载均衡模式，是依据接入WAN端带宽的大小比例，自动完成智能型负载均衡工作，进一步协助达成带宽使用率的优化目的。Qno侠诺在智能型负载均衡模式中，提供了联机数均衡与IP均衡两种选择。联机数均衡是依据WAN端带宽大小比例，将内网所有的联网机数作均衡分配。例如WAN1接入4M、WAN2接入2M，则联机数就会依据2:1分配。此种配置是网管员最一般的配置模式。

而IP均衡模式是为了避免某些网站（EX银行网站或HTTPS类型的网站），只能接受来自同一个公网IP的所发出封包的瓶颈。如果采用联机数智能型负载均衡模式，会发生该IP所发出的访问封包不一定是从固定WAN口流出，造成特定网站拒绝服务，导致断线的情况发生。如果采用IP均衡，让IP依据WAN端带宽大小进行比例均衡分配，例如WAN1与WAN2的带宽比例为2:1，则PC1、PC2走WAN1，PC3走WAN2，PC4、PC5走WAN1……，即可达到同一个内网PC所发出的应用服务封包，都从固定的WAN口（公网IP）流出，而整体内网IP也会依据带宽大小比例，自动进行均衡配置。此种配置比较适合常常需要进入特定网站时选择。

模式二：指定路由

指定路由比起智能型负载均衡而言，是保留了更多的自由设定弹性与例外原则。由于智能型负载均衡是针对整体内网联机数或是整体IP进行均衡分配。并不能个别指定某种应用服务、某个特定IP、某个特定网址，通过哪个WAN口出去。所以，有时会造成特定的服务（例如邮件、VOIP等）或特定的人士（公司老板、高管等）不能有享有优先或例外的不便。因此，指定路由是提供可配合协议绑定，先分别指定哪个应用服务、哪个IP网段、哪个目的网址，走哪个WAN端口。而其余剩下未绑定的部份，再进行智能型负载均衡，同样也有协议绑定模式或是IP均衡模式两种选择。

模式三：策略路由

由于大陆地区普遍存在电信、网通彼此互连不互通的跨网瓶颈。某家公司若同时接入电信网通线路，有时会明显发现要从电信去访问网通所提供的服务（如游戏下载等其它应用），会发现非常的缓慢，这就是服务器互访非常困难所造成的问题。

策略路由设定，让两个以上互连不互通的ISP线路分流，让电信服务走电信、网通服务走网通，加速服务存取的速度，可大大减低跨网的瓶颈。Qno侠诺在在产品的接口设计上采用了内建的网通策略模式，指定哪些WAN口只给网通走，即可快速设定完成。如果有其它的ISP线路需要做策略路由，也可采用自定的策略模式。策略路由除了普遍应用在电信网通分流之外，也同样可运用在跨国企业、校园网络专线、公众网络、医保专线与一般网络的双网配置架构中，可帮助整合、加速双网的服务质量。

问题三：双wan负载均衡和智能路由的区别主要在什么地方 智能路由主要是多了离线下载和存储功能。智能路由一般都是面向家用市场的。双WAN路由器主要是面向企业市场的。企业一般关注带宽优化、上网行为管理，智能化对企业没用处。

问题四：怎么使用路由器上负载均衡 就是让两条线路的度量值一样，以前去某个目的地只能走一条道，负载均衡就是分多条道去往目的地

问题五：静态路由均衡负载什么意思？ 多条静态路由的优先级相同（因为都是静态路由），如果链路的开销的度量值（一般为带宽）相同，那么定义为等价路由。

对于等价路由都会添加到活动路由表上，实现负载均衡也就是流量会根据均衡模式（一般为根据目的MAC，ip,source ip mac 为参考计算hash值决定从哪一条链路上），2条链路都转发包分担另一条链路的负担。

完全手打，忘采纳

问题六：如何实现路由器线路负载均衡 要实现负载均衡，第一步是创建一个访问列表，把你的网络分为两份。根据这个访问列表，你可以把一半的IP地址定义到一条线路上，把另一半IP地址定义到另一个线路上。假定你的网络是172.16.128.0/24。“允许IP地址10.172.16.128.0 0.0.0.254的访问列表1”将仅允许双数的IP地址。因此，你现在就有了两个子网。你还得根据每个请求和IP地址修改这个列表。现在你可以创建一个路由图。Route map 10 ISP1_primary(路由表10，第一家主要ISP)Match access-list 1 (与访问列表1相匹配)Set interface ISP1_interface(设接口为第一家主要ISP接口)Route map 20 ISP1_primary (路由表20，第一家主要ISP)Match access-list 1 (与访问列表1相匹配)Set interface ISP2_interface(设接口为第二家主要ISP接口)同样，你需要为第二家ISP创建另一个路由表。Route map 10 ISP2_primary(路由表10，第二家主要ISP)Match access-list 2 (与访问列表2相匹配)Set interface ISP2_interface (设接口为第二家主要ISP接口)Route map 20 ISP1_primary(路由表20，第二家主要ISP)Match access-list 2(与访问列表2相匹配)Set interface ISP1_interface(设接口为第一家主要ISP接口)访问列表2是与网络相匹配的另一个访问列表。你需要用自己的方法分割网络。还有一个选择就是在路由器上增加浮点静态路由。

问题七：路由器负载平衡，是什么意思，工具或者脚本有哪些 你的问题太专业了，想不用术语说明白基本很难，你先了解下负载平衡的概念和一些基本的吧。1、负载平衡（Loading Balance）是一种策略，能够将复杂计算或繁重的I／O任务在多台服务器或多条链路之间实现平衡分布。这一技术是建立在现有网络结构之上，能提供一种廉价有效的、透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高响应速度、从而以较低成本消除网络瓶颈，提高网络的灵活性和可用性。 ?

负载平衡可分为以下几类：?

1、本地负载平衡和异地负载平衡?

负载平衡按服务器所在位置分为本地负载平衡和异地负载平衡。本地负载平衡是指服务器群在同一地方，能解决本地关键Internet／Intranet应用服务器上的网络访问量大和网络负载过载等问题；异地负载平衡是指服务器存放在不同的地理位置、在不同网络结构的服务器群间作负载均衡。?

2、静态负载平衡和动态负载平衡?

负载平衡按照对任务的分配形式（负载的调度算法）分为静态负载平衡和动态负载平衡。在网络环境下，当负载平衡器(或均衡器负责任务分配的装置)收到客户的请求后，根据某一调度算法，将任务尽可能地分配到服务器群集中的各个服务器上，使各个服务器的客户请求数保持相对均衡，这就是静态负载平衡。其只能实现任务在服务器群集中静态分配，而不能考虑到任务繁简程度以及服务器的各自承载能力。?

动态负载平衡是指服务器群集中成员服务器执行负载后出现过载（或达到饱和）时，根据相应的调度算法，动态地将负载较重的服务器上的任务向服务器集群中的其他负载较轻的成员服务器上迁移，使服务器集群中成员服务器上的负载尽可能达到均匀。这一技术能实现任务迁移(或负载动态地分配)，能考虑到成员服务器的实际承载能力，在此间实现动态分配。?

3、软件负载平衡和硬件负载平衡?

软件负载均衡是指在一台或多台服务器相应的操作系统上安装能实现负载均衡功能的软件，如DNS Load Balance，Windows 2000 Applications Center Beta 2等，网管人员可以利用该软件进行服务器端的配置和通信管理，他的优点是服务器端配置简单、使用灵活、成本低廉，可满足架构中小企业级电子商务网站的负载平衡需求。?

硬件负载平衡是指基于负载分配器的一种负载分配策略，负载分配器（也称为负载均衡器）一般使用专用服务器、路由器等设备承担，所以这类设备的性能直接影响整个系统的服务质量。负载均衡器一般设在Intranet和Internet之间，具有较好的均衡策略、较高的效率和性价比。

问题八：负载均衡是什么意思？ 负载均衡提供扩展网络带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性的一种方法。在网络应用上，一开始并不需要负载均衡，当网络的访问量不断增长，无法满足负载需求时，也就是网络流量要出现瓶颈时，负载均衡才会起到作用。 打个比方，例如三台路由器首尾相连，用动态路由RIP配置，产生一个回路，由于到同一个网段有两条只有一条的RIP路由，就会用到负载均衡。 如有疑问，方可提出。

问题九：为什么路由器要配置 负载均衡 平衡多条链路的负载..反之一条链路压力过大而另一条链路空闲.另外还可以作为冗余链路提升链路保障.

问题十：等价路由和负载均衡是不是一回事 完全是两个概念，等价路由是后者的先决条件，后者的功能比前者强大很多

在软件系统的架构设计中，对集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。负载均衡本质上是用于将用户流量进行均衡减压的，因此在互联网的大流量项目中，其重要性不言而喻。

早期的互联网应用，由于用户流量比较小，业务逻辑也比较简单，往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大，稍微好一点的系统，访问量就非常大了，并且系统功能也越来越复杂，那么单台服务器就算将性能优化得再好，也不能支撑这么大用户量的访问压力了，这个时候就需要使用多台机器，设计高性能的集群来应对。

那么，多台服务器是如何去均衡流量、如何组成高性能的集群的呢？

此时就需要请出 「负载均衡器」 入场了。

负载均衡（Load Balancer）是指把用户访问的流量，通过「负载均衡器」，根据某种转发的策略，均匀的分发到后端多台服务器上，后端的服务器可以独立的响应和处理请求，从而实现分散负载的效果。负载均衡技术提高了系统的服务能力，增强了应用的可用性。

目前市面上最常见的负载均衡技术方案主要有三种：

基于DNS负载均衡

基于硬件负载均衡

基于软件负载均衡

三种方案各有优劣，DNS负载均衡可以实现在地域上的流量均衡，硬件负载均衡主要用于大型服务器集群中的负载需求，而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中，这三种是可以组合在一起使用。下面来详细讲讲：

基于DNS负载均衡

基于DNS来做负载均衡其实是一种最简单的实现方案，通过在DNS服务器上做一个简单配置即可。

其原理就是当用户访问域名的时候，会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP，北方的用户来访问的话，我就返回北京业务服务器所在的IP。

在这个模式下，用户就相当于实现了按照「就近原则」将请求分流了，既减轻了单个集群的负载压力，也提升了用户的访问速度。

使用DNS做负载均衡的方案，天然的优势就是配置简单，实现成本非常低，无需额外的开发和维护工作。

但是也有一个明显的缺点是：当配置修改后，生效不及时。这个是由于DNS的特性导致的，DNS一般会有多级缓存，所以当我们修改了DNS配置之后，由于缓存的原因，会导致IP变更不及时，从而影响负载均衡的效果。

另外，使用DNS做负载均衡的话，大多是基于地域或者干脆直接做IP轮询，没有更高级的路由策略，所以这也是DNS方案的局限所在。

基于硬件负载均衡

硬件的负载均衡那就比较牛逼了，比如大名鼎鼎的 F5 Network Big-IP，也就是我们常说的 F5，它是一个网络设备，你可以简单的理解成类似于网络交换机的东西，完全通过硬件来抗压力，性能是非常的好，每秒能处理的请求数达到百万级，即 几百万/秒 的负载，当然价格也就非常非常贵了，十几万到上百万人民币都有。

因为这类设备一般用在大型互联网公司的流量入口最前端，以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。

采用 F5 这类硬件做负载均衡的话，主要就是省心省事，买一台就搞定，性能强大，一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略，同时还具有一些防火墙等安全功能。但是缺点也很明显，一个字：贵。

基于软件负载均衡

软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡，分为7层协议 和 4层协议。

网络协议有七层，基于第四层传输层来做流量分发的方案称为4层负载均衡，例如 LVS，而基于第七层应用层来做流量分发的称为7层负载均衡，例如 Nginx。这两种在性能和灵活性上是有些区别的。

基于4层的负载均衡性能要高一些，一般能达到 几十万/秒 的处理量，而基于7层的负载均衡处理量一般只在 几万/秒 。

基于软件的负载均衡的特点也很明显，便宜。在正常的服务器上部署即可，无需额外采购，就是投入一点技术去优化优化即可，因此这种方式是互联网公司中用得最多的一种方式。

上面讲完了常见的负载均衡技术方案，那么接下来咱们看一下，在实际方案应用中，一般可以使用哪些均衡算法？

轮询策略

负载度策略

响应策略

哈希策略

下面来分别介绍一下这几种均衡算法/策略的特点：

NO.1—— Random 随机

这是最简单的一种，使用随机数来决定转发到哪台机器上。

优点：简单使用，不需要额外的配置和算法。

缺点：随机数的特点是在数据量大到一定量时才能保证均衡，所以如果请求量有限的话，可能会达不到均衡负载的要求。

NO.2—— Round Robin 轮询

这个也很简单，请求到达后，依次转发，不偏不向。每个服务器的请求数量很平均。

缺点：当集群中服务器硬件配置不同、性能差别大时，无法区别对待。引出下面的算法。

NO.3—— Weighted Round Robin 加权轮询

这种算法的出现就是为了解决简单轮询策略中的不足。在实际项目中，经常会遇到这样的情况。

比如有5台机器，两台新买入的性能等各方面都特别好，剩下三台老古董。这时候我们设置一个权重，让新机器接收更多的请求。物尽其用、能者多劳嘛！

这种情况下，“均衡“就比较相对了，也没必要做到百分百的平均。

NO.4—— Least Connections 最少连接

这是最符合负载均衡算法的一个。需要记录每个应用服务器正在处理的连接数，然后将新来的请求转发到最少的那台上。

NO.5—— Source Hashing 源地址散列

根据请求的来源ip进行hash计算，然后对应到一个服务器上。之后所有来自这个ip的请求都由同一台服务器处理。