1. 负载均衡支持哪些调度算法？

可以使用轮询、加权轮询（WRR）、加权最小连接数（WLC）这三种调度方法：

• 轮询：按照访问次数依次将外部请求依序分发到后端ECS上。
• 加权轮询：您可以对每台后端服务器设置权重值，权重值越高的服务器，被轮询到的次数（概率）也越高。
• 加权最小连接数：除了根据每台后端服务器设定的权重值来进行轮询，同时还考虑后端服务器的实际负载（即连接数）。当权重值相同时，当前连接数越小的后端服务器被轮询到的次数（概率）也越高。

2. 公网负载均衡和私网负载均衡的区别是什么？

• 公网类型的负载均衡可以对公网提供服务，实例创建后的服务地址是公网IP地址。
• 私网类型的负载均衡仅可以在阿里云内部使用，实例创建后的服务地址是内网IP地址。

3. 是否可以修改负载均衡实例类型？

不可以。

因为负载均衡系统会根据负载均衡实例类型来分配不同的服务地址（公网IP或私网IP），所以当您要进行负载均衡实例类型切换操作时，必须通过先删除后创建的方式，在新建实例时重新选择负载均衡实例类型。

4. 负载均衡分配的IP是否为独占？

在您购买使用负载均衡服务的整个生命周期内，该服务地址都是由您所购买的服务独占的。更改负载均衡配置和监听策略不会导致负载均衡服务地址的变更。

如果您的负载均衡服务地址已经正常解析到域名且对外提供服务，除非必要请不要删除对应的负载均衡实例。负载均衡实例删除后，相应的服务配置和服务地址将会被释放掉，数据一旦删除，不可恢复。如果您重新创建负载均衡服务，系统会重新给您分配一个新的服务地址。

5. 负载均衡是否支持端口跳转？

目前负载均衡是不支持端口跳转功能的。如果您想实现端口跳转，例如80端口跳转到443端口，只能在后端的服务器上做相关的跳转操作。

6. ping负载均衡的IP和ping负载均衡后端ECS的IP有什么区别？

ping负载均衡的IP是由负载均衡集群响应，不会转发给后端的ECS；ping负载均衡后端ECS是由后端ECS直接去响应，与前端的负载均衡没有关联关系。

7. 负载均衡是否依赖外网带宽？

负载均衡和后端ECS之间是通过内网进行通信的，所以ECS无需配置外网带宽。

如果您的业务存在同时通过负载均衡和ECS提供对外服务的需要，但那么相应的ECS需要具备足够支撑业务的外网带宽。负载均衡的服务能力与后端ECS的公网带宽规格无关。

8. 禁用公网网卡是否影响负载均衡服务？

如果ECS有公网IP，禁用公网网卡就会影响负载均衡服务。

因为在有公网网卡的情况下，默认路由会走公网，如禁用就无法回包从而影响负载均衡服务。建议不要禁止，如一定要这么做，需要修改默认路由为私网才会不影响服务。但需要考虑业务是否对公网有依赖，如通过公网访问RDS等。

9. 如何避免负载均衡服务本身的故障问题？

• 添加不同可用区的ECS实例作为负载均衡实例的后端服务器，从而提高本地可用性。
• 在同一地域创建多个负载均衡实例，通过DNS轮询的方式对外提供服务，从而提高本地可用性。
• 在不同地域创建多个负载均衡实例，通过DNS轮询的方式对外提供服务，从而提高跨地域的可用性。

10. 负载均衡均衡的是什么？

负载均衡是按特定调度算法把流量分发到后端ECS上，其中：

• 四层（TCP和UDP）是基于连接做流量做调度。TCP和UDP创建一个socket访问负载均衡实例，这个源和目的IP和端口就是一个连接。
• 七层（HTTP/HTTPS）是基于请求做调度。比如http get请求访问一个页面。

11. 为什么请求不均衡？

负载均衡请求不均衡的原因可能有以下几种可能：

• 开启了会话保持功能配置了会话保持，当访问负载均衡实例的客户端又很少时，容易导致不均衡，尤其在使用少量客户端对负载均衡进行测试的时候。比如TCP监听，开启了会话保持（四层是基于来源地址做会话保持），使用一台客户端对负载均衡实例进行压测，就会导致不均衡。
• ECS健康检查异常后端服务器ECS的健康建状态异常会导致不均衡，尤其在压测的时候容易忽略后端服务器ECS的健康检查状态，如果有后端服务器ECS健康检查失败或者健康检查状态经常跳跃（好到坏，又从坏到好，反复变化）必然会导致不均衡。
• TCP Keepalive保持长连接后端服务器ECS有些开启了TCP Keepalive保持长连接，而有些又没有开启，则连接会在保持长连接的后端服务器上堆积，造成不均衡。
• 排查和解决方法
  • 查看后端各台ECS的权重是否相同；
  • 在相关时间段内是否有健康检查失败或波动现象（查vnet或sls日志），查找波动的原因；或者健康检查没有配置正确的响应码2xx，3xx导致了健康检查显示正常，但后端服务有异常；
  • 是否同时使用了加权最小连接数（WLC）调度方式和会话保持，如果是，尝试改为加权加权轮询（WRR）算法和会话保持。

12. 为什么每个连接达不到带宽峰值？

因为负载均衡系统通过集群部署的方式为负载均衡实例提供服务，所有外部的访问请求都将平均分散到这些负载均衡系统服务器上进行转发。所以，设定的带宽峰值将被平均设定在多台系统服务器上。

单个连接下载的流量上限计算方法为：单个连接下载峰值=设置的负载均衡总带宽/(N-1)。N为流量转发分组个数，当前值为4。比如您在控制台上设置的是10Mb带宽上限，那么单个客户端可下载的最大流量为10/(4-1)=3.33Mb。

基于负载均衡的实现原理，建议在配置单个监听的带宽峰值时根据您实际的业务情况并结合其实现方式来设定一个较为合理的值，从而确保您业务的正常对外服务不会受到影响和限制。

13. 为什么负载均衡压缩失败？

查看文件的content-type属性，如果文件类型不是text/xml、text/plain、text
/css、
application/javascript、application/x-javascript、application/rss+xml、
application/atom+xml或application/xml，则压缩失败。

解决方法：

• 在源站修改该文件的content-type属性，改成负载均衡支持的文件类型。
• 将七层负载均衡实例监听修改为四层实例监听。

14. 如何查询负载均衡带宽和流量使用情况？

• 消费明细打开费用中心管理控制台，在费用中心导航栏，单击消费记录 > 消费明细。产品选择负载均衡，查看负载均衡的消费明细。
• 流量使用情况在负载均衡实例详情页面，单击监控，查看流量使用情况。
  

  负载均衡的监控数据和您的消费明细中的流量数据会有些差距，详情查看监控数据与计量数据。 whycallAPIFAILE

15. 为什么调用API修改带宽失败？

如果调用API修改带宽失败，报错Code":"InvalidParameter","Message":"The specified parameter bandwidth is not valid."，则说明控制台上配置监听设置的带宽大于通过API修改的负载均衡实例带宽，这时是变更失败的。您需要在控制台上更改带宽限制。

16. 负载均衡监控数据与实际账单数据为什么不同？

• 负载均衡控制台监控指标中展示的实例流量数据是按照一分钟一个采集粒度，由负载均衡系统采集后上报云监控系统，再由云监控系统计算出每15分钟所
  有采集点的平均值；而负载均衡实例的账单计量数据是按照同样粒度的采集频度采集数据，在一个消费帐期后，以1个小时的累加值向账单计量系统上报并结算费用
  的。账单数据是每一分钟的累加值，而监控数据是每15分钟平均值的累加值。所以，这两组数据在实际计算生成方式上是有区别的，两种数据不具备对比性。
• 负载均衡系统从采集数据到向云监控上报数据，然后云监控对数据进行平均值计算，最后展示在监控控制台的整个过程中，不可避免的存在一定的延迟。虽
  然这个延迟很小，我们也会尽量保证数据的实时性，但这种延迟也会导致其数据本身与账单计量数据存在一定程度的差异。用作计费的账单计量数据是可以容忍最多
  三小时延迟的，比如在01:00-02:00产生的账单计量数据，正常情况下会在03:00之前由负载均衡上报账单计量系统并进行计费，但是系统允许该上
  报时间最晚于05:00之前完成并计费。所以，从数据对实时性的要求不同来看，这两组数据也是不具备可比性的。
• 从监控和账单计量的产品定义上也是有区别的。监控的目的是为了通过一种手段来观察被监控实例的运行状态是否会出现异常，从而针对性地采取一定措施
  来解决由于异常导致的问题。账单计量的目的是根据实例的实际资源消耗情况来进行计费。所以，从账单核算的出发点来看应该是以账单计量系统生产的数据来作为
  计费的判断依据而不应该以监控数据作为计费的判断依据。

17. 负载均衡各监听连接超时时间是多少？

• TCP监听： 900秒
• UDP监听： 300秒
• HTTP监听： 60秒
• HTTPS监听： 60秒

18. 为什么负载均衡服务地址会连接访问超时？

从服务端分析，以下情况会导致服务地址链接访问超时:

• 服务地址被安全防护如流量黑洞和清洗，WAF防护（WAF的特点是建连后向客户端和服务器集群双向发送RST报文）。
• 客户端端口不足尤其容易发生在压测的时候，客户端端口不足会导致建立连接失败，负载均衡默认会抹除TCP连接的timestamp属性，Linux协议栈的tw_reuse(time_wait状态连接复用)无法生效，time_wait状态连接堆积导致客户端端口不足。解决方法：客户端端使用长连接代替短连接。使用RST报文断开连接（socket设置SO_LINGER属性） ，而不是发FIN包这种方式断开。
• 后端服务器accept队列满后端服务器accept队列满，导致后端服务器不回复syn_ack报文，客户端超时。解决方法：默认的net.core.somaxconn的值为128，执行sysctl -w net.core.somaxconn=1024更改它的值，并重启后端服务器上的应用。
• 从四层负载均衡后端服务器访问该四层负载均衡的服务地址四层负载均衡，在该负载均衡的后端服务器上去访问该负载均衡的服务地址会导致连接失败，常见的场景是后端应用使用URL拼接的方式跳转访问。
• 对连接超时的RST处理不当负载均衡上建立TCP连接后，如果900s未活动，则会向客户端和服务器双向发送RST断开连接，有的应用对RST异常处理不当，可能会对已关闭的连接再次发送数据导致应用超时。