电信移动均衡负载稳定吗？

一、电信移动均衡负载稳定吗？

并不可以，因为不是一种设备所以输出电压功率不一致，造成了负载部分电

二、负载均衡，标准？

负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。

负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

一.负载均衡原理

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

l 应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理，并返回相应数据。

l 负载均衡设备：将用户访问的请求，根据负载均衡算法，分发到集群中的一台处理服务器。（一种把网络请求分散到一个服务器集群中的可用服务器上去的设备）

负载均衡的作用（解决的问题）：

1.解决并发压力，提高应用处理性能（增加吞吐量，加强网络处理能力）；

2.提供故障转移，实现高可用；

3.通过添加或减少服务器数量，提供网站伸缩性（扩展性）；

4.安全防护；（负载均衡设备上做一些过滤，黑白名单等处理）

二. 负载均衡分类

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

2.1 DNS负载均衡

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

优点

1>. 使用简单：负载均衡工作，交给DNS服务器处理，省掉了负载均衡服务器维护的麻烦；

2>. 提高性能：可以支持基于地址的域名解析，解析成距离用户最近的服务器地址，可以加快访问速度，改善性能；

缺点

1>. 可用性差：DNS解析是多级解析，新增/修改DNS后，解析时间较长；解析过程中，用户访问网站将失败；

2>. 扩展性低：DNS负载均衡的控制权在域名商那里，无法对其做更多的改善和扩展；

3>.SPAN>

实践建议

将DNS作为第一级负载均衡，A记录对应着内部负载均衡的IP地址，通过内部负载均衡将请求分发到真实的Web服务器上。一般用于互联网公司，复杂的业务系统不合适使用。

2.2 IP负载均衡

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

用户请求数据包，到达负载均衡服务器后，负载均衡服务器在操作系统内核进程获取网络数据包，根据负载均衡算法得到一台真实服务器地址，然后将请求目的地址修改为，获得的真实ip地址，不需要经过用户进程处理。

真实服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器，再将数据包源地址修改为自身的ip地址，发送给用户浏览器。

IP负载均衡，真实物理服务器返回给负载均衡服务器，存在两种方式：（1）负载均衡服务器在修改目的ip地址的同时修改源地址。将数据包源地址设为自身盘，即源地址转换（snat）。（2）将负载均衡服务器同时作为真实物理服务器集群的网关服务器。

优点：在内核进程完成数据分发，比在应用层分发性能更好；

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

2.4 链路层负载均衡

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

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

实际处理服务器ip和数据请求目的ip一致，不需要经过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。也称为直接路由模式（DR模式）。

优点：性能好；

缺点：配置复杂；

实践建议：DR模式是目前使用最广泛的一种负载均衡方式。

2.5混合型负载均衡

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

此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。是目前大型互联网公司，普遍使用的方式。

以上模式适合有动静分离的场景，反向代理服务器（集群）可以起到缓存和动态请求分发的作用，当时静态资源缓存在代理服务器时，则直接返回到浏览器。如果动态页面则请求后面的应用负载均衡（应用集群）。

三、EPG负载均衡错误？

EPG主页地址没有通过有效性检测。针对EPG主页地址的域名解析失败。多次重试连接EPG主页地址失败，无法与其建立连接。建议解决办法：新开户的机顶盒请检查机顶盒的主认证服务器地址是否配置正确。配置的地址为域名方式，可以通过Monitor工具连5030端口查看日志，确认是否域名解释失败。检查机顶盒实际连接边缘EPG的MTU值的设置是否正确。

四、activemq负载均衡原理？

Activemq 的作用就是系统之间进行通信。 当然可以使用其他方式进行系统间通信， 如果使用 Activemq 的话可以对系统之间的调用进行解耦，

实现系统间的异步通信。 原理就是生产者生产消息， 把消息发送给activemq。 Activemq 接收到消息， 然后查看有多少个消费者，

然后把消息转发给消费者， 此过程中生产者无需参与。 消费者接收到消息后做相应的处理和生产者没有任何关系

五、rabbion负载均衡算法？

1、轮询调度 　　轮询调度算法就是以轮询的方式依次将请求调度到不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。 　

2、最小连接调度 　　最小连接调度算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。 　　在实际实现过程中，一般会为每台服务器设定一个权重值，这就是加权最小连接 　　

3、 基于局部性的最少链接(LBLC) 　　基于局部性的最少链接调度(以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。 　　LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器; 若服务器不存在，或服务器超载或有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器。 　　

4、带复制的基于局部性最少链接(LBLCR) 　　带复制的基于局部性最少链接调度以下简称为LBLCR)算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。 　　LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合)，当该“热门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载; 当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器数目。 　　

5、目标地址散列调度 　　目标地址散列调度算法是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。 　　目标地址散列调度算法先根据请求的目标IP地址，作为散列从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。 　　

6、 源地址散列调度 　　和目标地址散列调度类似，唯一的区别是按照源地址为散列函数的散列键。

六、负载均衡的区别？

负载均衡是一种将工作负载分配到多个服务器或计算资源上的技术，以提高系统的性能、可靠性和可扩展性。它可以通过不同的方式实现，有以下几种常见的负载均衡方式及其区别：

基于硬件的负载均衡：使用专用的硬件设备（如负载均衡器）来分发流量和请求。这些设备通常具有高性能和可靠性，并提供丰富的负载均衡算法和功能。它们可以在网络层或应用层进行负载均衡，并能够处理大量的并发请求。

基于软件的负载均衡：使用软件来实现负载均衡功能，通常在服务器上运行。这种方式可以通过软件负载均衡器、反向代理服务器或应用程序级别的负载均衡来实现。它相对于硬件负载均衡来说成本较低，但性能可能会受到服务器资源的限制。

DNS负载均衡：通过DNS服务器将请求分发到不同的服务器上。DNS负载均衡可以根据不同的策略（如轮询、加权轮询、最少连接等）将请求分发到不同的IP地址，从而实现负载均衡。然而，DNS负载均衡的效果可能受到DNS缓存和TTL（Time to Live）的影响。

内容分发网络（CDN）：CDN是一种分布式的网络架构，通过将内容缓存到离用户更近的边缘节点上，以提供更快的访问速度和更好的用户体验。CDN可以根据用户的地理位置和网络状况来选择最佳的边缘节点，从而实现负载均衡。

总体而言，不同的负载均衡方式适用于不同的场景和需求。硬件负载均衡器通常适用于大规模、高性能的环境，而软件负载均衡和DNS负载均衡适用于中小规模的环境。CDN则适用于需要提供全球范围内快速访问的应用。选择适合自己需求的负载均衡方式需要考虑到性能、可靠性、成本和可扩展性等因素。

七、dubbo负载均衡原理？

Remoting：网络通信框架，实现了sync-over-async和request-response消息机制。

RPC：一个远程过程调用的抽象，支持负载均衡、容灾和集群功能。

Registry：服务目录框架用于服务的注册和服务事件发布和订阅。（类似第一篇文章中的点菜宝）

dubbo架构

Provider： 暴露服务的提供方。

Consumer：调用远程服务的服务消费方。

Registry： 服务注册中心和发现中心。

Monitor： 统计服务和调用次数，调用时间监控中心。（dubbo的控制台页面中可以显示）

Container：服务运行的容器。

调用关系：

0、服务器负责启动，加载，运行提供者（例如在tomcat容器中，启动dubbo服务端）。

1、提供者在启动时，向注册中心注册自己提供的服务。

2、消费者启动时，向注册中心订阅自己所需的服务。

3、注册中心返回提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4、消费者，从远程接口列表中，调用远程接口，dubbo会基于负载均衡算法，选一台提供者进行调用，如果调用失败则选择另一台。

5、消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。（可以在dubbo的可视化界面看到）

dubbo的容错方案

当我们的系统中用到Dubbo的集群环境,因为各种原因在集群调用失败时，Dubbo提供了多种容错方案，缺省为failover重试。

Dubbo的集群容错在这里想说说他是因为我们实际的项目中出现了此类的问题,因为依赖的第三方项目出现异常,导致dubbo调用超时,此时使用的是默认的集群容错方式,而配置的reties='3',这样前段系统连续掉用了三次服务,结果可想而知.

先说一下各节点关系：

这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息。

Directory代表多个Invoker，可以把它看成List<Invoker>，但与List不同的是，它的值可能是动态变化的，比如注册中心推送变更。

Cluster将Directory中的多个Invoker伪装成一个Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个。

Router负责从多个Invoker中按路由规则选出子集，比如读写分离，应用隔离等。

LoadBalance负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选。

集群容错模式：

Failover Cluster

失败自动切换，当出现失败，重试其它服务器。(缺省)

通常用于读操作，但重试会带来更长延迟。

可通过retries="2"来设置重试次数(不含第一次)。正是文章刚开始说的那种情况.

Failfast Cluster

快速失败，只发起一次调用，失败立即报错。

通常用于非幂等性的写操作，比如新增记录。

Failsafe Cluster

失败安全，出现异常时，直接忽略。

通常用于写入审计日志等操作。

Failback Cluster

失败自动恢复，后台记录失败请求，定时重发。

通常用于消息通知操作。

Forking Cluster

并行调用多个服务器，只要一个成功即返回。

通常用于实时性要求较高的读操作，但需要浪费更多服务资源。

可通过forks="2"来设置最大并行数。

Broadcast Cluster

广播调用所有提供者，逐个调用，任意一台报错则报错。(2.1.0开始支持)

通常用于通知所有提供者更新缓存或日志等本地资源信息。

重试次数配置如：(failover集群模式生效)

<dubbo:serviceretries="2"/>

或：<dubbo:referenceretries="2"/>

或：<dubbo:reference>

<dubbo:methodname="findFoo"retries="2"/>

</dubbo:reference>

集群模式配置如：

<dubbo:servicecluster="failsafe"/>

或：<dubbo:referencecluster="failsafe"/>

dubbo负载均衡策略：

在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。

RandomLoadBalance

随机，按权重设置随机概率。

在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

轮循，按公约后的权重设置轮循比率。

存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。

使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHashLoadBalance

一致性Hash，相同参数的请求总是发到同一提供者。

当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

Dubbo的集群容错和负载均衡同样也是Dubbo本身的高级特性.正如我们在说自定义扩展的时候一样,这两个特征同样也可以进行自定义扩展,用户可以根据自己实际的需求来扩展他们从而满足项目的实际需求.

八、apache负载均衡原理？

实现负载均衡的原理为：假设Apache接收到http://127.0.0.1 /test请求,由于该请求满足ProxyPass条件(其URL前缀为“/"),该请求会 被分发到后台某一个BalancerMember。

譬如该请求可能会转发到http://127.0.0.1:8080/进行处理。

当第二个满足条件的URL请求过来时,该请求可能会被分发到另外一台BalancerMember,譬如,可能会转发到 http://127.0.0.1:7080/如此循环反复,便实现了负载均衡的机制。

九、nigx负载均衡原理？

所谓负载均衡，就是 Nginx 把请求均匀的分摊给上游的应用服务器，这样即使某一个服务器宕机也不会影响请求的处理，或者当应用服务器扛不住了，可以随时进行扩容。

在 x 轴上，可以通过横向扩展应用服务器集群，Nginx 基于 Round-Robin 或者 Least-Connected 算法分发请求。但是横向扩展并不能解决所有问题，当数据量大的情况下，无论扩展多少台服务，单台服务器数据量依然很大。

在 y 轴上，可以基于 URL 进行不同功能的分发。需要对 Nginx 基于 URL 进行 location 的配置，成本较高。

在 z 轴上可以基于用户信息进行扩展。例如将用户 IP 地址或者其他信息映射到某个特定的服务或者集群上去。

这就是 Nginx 的负载均衡功能，它的主要目的就是为了增强服务的处理能力和容灾能力。

十、emmc 负载均衡原理？

emmc 负载均衡一种基础的网络服务，其原理是通过运行在前面的负载均衡服务，按照指定的负载均衡算法，将流量分配到后端服务集群上，从而为系统提供并行扩展的能力。

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