• 关于

    程序性能未响应

    的搜索结果

问题

最大限度利用 JavaScript 和 Ajax 性能:报错

简介 在 web 早期,优化 web 页面的性能通常意味着避免了使用不必要的 HTML 标记,将 JavaScript 代码量控制到最小,并尽量减小所有图片文件大小,否则上网冲浪者会...
kun坤 2020-06-05 22:56:50 0 浏览量 回答数 1

问题

某政务网站性能优化

门户类网站性能测试分析及调优 1 背景   前段时间,性能测试团队经历了一个规模较大的门户网站的性能优化工作,该网站的开发和合作涉及多个组织和部门,而且网站的重要性不言而喻,同时上...
猫饭先生 2019-12-01 21:25:38 1412 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:11 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:12 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台ECS健康检查出现异常时,负载均衡会自动将新的请求分发到其它健康检查正常的ECS上;而当该ECS恢复正常运行时,负载均衡会将其自动恢复到负载均衡服务中。 如果您的业务对负载敏感性高,高频率的健康检查探测可能会对正常业务访问造成影响。您可以结合业务情况,通过降低健康检查频率、增大健康检查间隔、七层检查修改为四层检查等方式,来降低对业务的影响。但为了保障业务的持续可用,不建议关闭健康检查。 健康检查过程 负载均衡采用集群部署。LVS集群或Tengine集群内的相关节点服务器同时承载了数据转发和健康检查职责。 LVS集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果某一台LVS节点服务器对后端某一台ECS健康检查失败,则该LVS节点服务器将不会再将新的客户端请求分发给相应的异常ECS。LVS集群内所有服务器同步进行该操作。 负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。 HTTP/HTTPS监听健康检查机制 针对七层(HTTP或HTTPS协议)监听,健康检查通过HTTP HEAD探测来获取状态信息,如下图所示。 对于HTTPS监听,证书在负载均衡系统中进行管理。负载均衡与后端ECS之间的数据交互(包括健康检查数据和业务交互数据),不再通过HTTPS进行传输,以提高系统性能。 七层监听的检查机制如下: Tengine节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD请求(包含设置的【域名】)。 后端ECS收到请求后,根据相应服务的运行情况,返回HTTP状态码。 如果在【响应超时时间】之内,Tengine节点服务器没有收到后端ECS返回的信息,则认为服务无响应,判定健康检查失败。 如果在【响应超时时间】之内,Tengine节点服务器成功接收到后端ECS返回的信息,则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功,反之则判定健康检查失败。 TCP监听健康检查机制 针对四层TCP监听,为了提高健康检查效率,健康检查通过定制的TCP探测来获取状态信息,如下图所示。 TCP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送TCP SYN数据包。 后端ECS收到请求后,如果相应端口正在正常监听,则会返回SYN+ACK数据包。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的数据包,则认为服务无响应,判定健康检查失败;并向后端ECS发送RST数据包中断TCP连接。 如果在【响应超时时间】之内,LVS节点服务器成功收到后端ECS返回的数据包,则认为服务正常运行,判定健康检查成功,而后向后端ECS发送RST数据包中断TCP连接。 说明 正常的TCP三次握手,LVS节点服务器在收到后端ECS返回的SYN+ACK数据包后,会进一步发送ACK数据包,随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端ECS认为相关TCP连接出现异常(非正常退出),并在业务软件如Java连接池等日志中抛出相应的错误信息,如Connection reset by peer。 解决方案: TCP监听采用HTTP方式进行健康检查。 在后端ECS配置了获取客户端真实IP后,忽略来自前述负载均衡服务地址段相关访问导致的连接错误。 UDP监听健康检查 针对四层UDP监听,健康检查通过UDP报文探测来获取状态信息,如下图所示。 UDP监听的检查机制如下: LVS节点服务器根据监听的健康检查配置,向后端ECS的内网IP+【健康检查端口】发送UDP报文。 如果后端ECS相应端口未正常监听,则系统会返回类似返回 port XX unreachable的ICMP报错信息;反之不做任何处理。 如果在【响应超时时间】之内,LVS节点服务器收到了后端ECS返回的上述错误信息,则认为服务异常,判定健康检查失败。 如果在【响应超时时间】之内,LVS节点服务器没有收到后端ECS返回的任何信息,则认为服务正常,判定健康检查成功。 说明 当前UDP协议服务健康检查可能存在服务真实状态与健康检查不一致的问题: 如果后端ECS是Linux服务器,在大并发场景下,由于Linux的防ICMP攻击保护机制,会限制服务器发送ICMP的速度。此时,即便服务已经出现异常,但由于无法向前端返回port XX unreachable报错信息,会导致负载均衡由于没收到ICMP应答进而判定健康检查成功,最终导致服务真实状态与健康检查不一致。 解决方案: 负载均衡通过发送您指定的字符串到后端服务器,必须得到指定应答后才认为检查成功。但该实现机制需要客户端程序配合应答。 健康检查时间窗 健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。健康检查时间窗由以下三个因素决定: 健康检查间隔 (每隔多久进行一次健康检查) 响应超时时间 (等待服务器返回健康检查的时间) 检查阈值 (健康检查连续成功或失败的次数) 健康检查时间窗的计算方法如下: 健康检查失败时间窗=响应超时时间×不健康阈值+检查间隔×(不健康阈值-1) 健康检查成功时间窗= (健康检查成功响应时间x健康阈值)+检查间隔x(健康阈值-1) 说明 健康检查成功响应时间是一次健康检查请求从发出到响应的时间。当采用TCP方式健康检查时,由于仅探测端口是否存活,因此该时间非常短,几乎可以忽略不计。当采用HTTP方式健康检查时,该时间取决于应用服务器的性能和负载,但通常都在秒级以内。 健康检查状态对请求转发的影响如下: 如果目标ECS的健康检查失败,新的请求不会再分发到相应ECS上,所以对前端访问没有影响。 如果目标ECS的健康检查成功,新的请求会分发到该ECS上,前端访问正常。 如果目标ECS存在异常,正处于健康检查失败时间窗,而健康检查还未达到检查失败判定次数(默认为三次),则相应请求还是会被分发到该ECS,进而导致前端访问请求失败。
2019-12-01 23:31:10 0 浏览量 回答数 0

问题

如何在云数据库 Redis 版中进行管道传输

场景介绍 云数据库 Redis 版提供了与 Redis 相同的管道传输(pipeline)机制。管道(pipeline)将客户端 client 与服务器端的交互明确划分为单向的发送...
云栖大讲堂 2019-12-01 21:20:29 1036 浏览量 回答数 0

问题

支付宝的性能测试

       一、性能测试支付宝场景介绍   2013年双11过程当中,促销开启的第一分钟内支付宝的交易总额就突破了一亿元,短时间内大量用户涌入的情况下,如何保证用户的支付顺畅,...
云效平台 2019-12-01 21:47:13 5472 浏览量 回答数 1

问题

PHP开发中的外围资源性能分析(一)

暂且不讨论「PHP 是不是最好的编程语言」,本文我们将分别分析一下在 PHP 程序的后端外围资源和前端外围资源,它们对整个 PHP Web 应用体验的影响,这往往比语言本身大得多。 首先ÿ...
sunny夏筱 2019-12-01 21:45:29 6222 浏览量 回答数 1

问题

【精品问答】性能测试 PTS

性能测试 PTS(Performance Testing Service)是具备强大的分布式压测能力的 SaaS 压测平台,可模拟海量用户的真实业务场景,全方位验证业务站点的性能、容量...
montos 2020-04-08 13:18:48 2 浏览量 回答数 1

问题

Nginx性能为什么如此吊

Nginx性能为什么如此吊,Nginx性能为什么如此吊,Nginx性能为什么如此吊 (重要的事情说三遍)的性能为什么如此吊!!!         最近几年,web架构拥抱解耦的...
小柒2012 2019-12-01 21:20:47 15038 浏览量 回答数 3

问题

健康检查原理

概述 负载均衡通过健康检查来判断后端服务器(ECS实例)的业务可用性。健康检查机制提高了前端业务整体可用性,避免了后端ECS异常对总体服务的影响。 开启健康检查功能后,当后端某台E...
行者武松 2019-12-01 21:36:16 1626 浏览量 回答数 0

问题

小试用,大学问菜鸟也要知道如何去试用之云服务器测评

        相信各位都知道云服务器的三大省,省时、省力、省钱。很多人转到云主机来,也是因为这个原因,独立主机的高昂费用,合租的不稳定,虚拟主机的不靠谱,...
universitylife 2019-12-01 21:15:34 33359 浏览量 回答数 19

问题

小试用,大学问菜鸟也要知道如何去试用之云服务器测评

        相信各位都知道云服务器的三大省,省时、省力、省钱。很多人转到云主机来,也是因为这个原因,独立主机的高昂费用,合租的不稳定,虚拟主机的不靠谱,...
universitylife 2019-12-01 21:31:33 15660 浏览量 回答数 10

回答

Java之JVM垃圾回收 内存结构以及垃圾回收算法前言:由于小组技术分享的需要,懂的不是很多所以我就找了这个我自己感兴趣的知识点给大家做个简单的介绍。由于是新人,算不了很懂,只是总结性的讲了些概念性的东西。给大家分享的同时,算是给自己做个笔记吧。作为Java语言的核心之一,JVM垃圾回收帮我们解决了让我们很头疼的垃圾回收问题。我们不需要像VC++一样,作为内存管理的统治者需要我们对我们分配的每一块内存进行回收,否则就会造成内存泄露问题。是不是只要有JVM存在我们就不会出现内存泄露问题,出现内存泄露问题我们又该怎么办,如果我们想提高我们程序的稳定性和其他性能我们能从什么地方下手!!!相信这些问题是我们程序过程中不可逾越的。了解JVM的内存分配及其相应的垃圾回收机制,不仅仅是可以了解底层的JVM运行机制,而且对于程序性能的优化和提升还是很有必要的。一、JVM内存分配区域结构图一从图一可以看出JVM中的内存分配包括PC Register(PC寄存器) JVM栈 堆(Heap) 方法区域(MethodArea)运行时常量池(RuntimeConstant Pool) 本地方法堆栈(NativeMethod Stacks),这几部分区域但是从程序员的角度来看我们只关注JVM Heap和JVM Stack,因为这两部分是直接关系程序运行期间的内存状态,所以我会主要介绍这两部分内存,其他的我只是给出了简单的一些概念性解释:PC Register(Program Counter 寄存器):主要作用是记录当前线程所执行的字节码的行号。方法区域(MethodArea):方法区域存放了所加载的类的信息(名称、修饰符等)、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息,法区域也是全局共享的,它在虚拟机启动时在一定的条件下它也会被GC,当方法区域需要使用的内存超过其允许的大小时,会抛出OutOfMemory的错误信息。运行时常量池(RuntimeConstant Pool):存放的为类中的固定的常量信息、方法和Field的引用信息等,其空间从方法区域中分配。本地方法堆栈(NativeMethod Stacks):JVM采用本地方法堆栈来支持native方法的执行,此区域用于存储每个native方法调用的状态。JVM栈:主要存放一些基本类型的变量和对象的引用变量。JVM堆:用来存放由 new 创建的对象和数组Java 虚拟机的自动垃圾回收器来管理(注意数组也是对象,所以说数组也是存放在JVM堆中)。由于栈中存放的是主要存放一些基本类型的变量和对象的引用变量,所以当过了变量的作用区域或者是当程序运行结束后它所占用的内存会自动的释放掉,所以不用来关心,下面我们主要来说的是堆内存的分配以及回收的算法。二、JVM堆内存介绍工欲善其事,必先利其器。所以了解堆内存的内部结构是很必要的。在Jvm中堆空间划分为三个代:年轻代(Young Generation)、年老代(Old Generation)和永久代(Permanent Generation)。年轻带主要是动态的存储,年轻带主要储存新产生的对象,年老代储存年龄大些的对象,永久带主要是存储的是java的类信息,包括解析得到的方法、属性、字段等。永久带基本不参与垃圾回收。所以说我们说的垃圾回收主要是针对年轻代和年老代。图二年轻代又分成3个部分,一个eden区和两个相同的survior区。刚开始创建的对象都是放置在eden区的。分成这样3个部分,主要是为了生命周期短的对象尽量留在年轻带。当eden区申请不到空间的时候,进行minorGC,把存活的对象拷贝到survior。年老代主要存放生命周期比较长的对象,比如缓存对象。(经过IBM的一个研究机构研究数据表明,基本上80%-98%的对象都会在年轻代的Eden区死掉从而本回收掉,所以说真正进入到老年代的对象很少,这也是为什么MinorGC比MajorGC更加频繁的原因)具体JVM内存垃圾回收过程描述如下 :1、对象在Eden区完成内存分配2、当Eden区满了,再创建对象,会因为申请不到空间,触发minorGC,进行young(eden+1survivor)区的垃圾回收3、minorGC时,Eden不能被回收的对象被放入到空的survivor(Eden肯定会被清空),另一个survivor里不能被GC回收的对象也会被放入这个survivor,始终保证一个survivor是空的4、当做第3步的时候,如果发现survivor满了,则这些对象被copy到old区,或者survivor并没有满,但是有些对象已经足够Old,也被放入Old区 XX:MaxTenuringThreshold5、当Old区被放满的之后,进行fullGC补充: MinorGC:年轻代所进行的垃圾回收,非常频繁,一般回收速度也比较快。 MajorGC:老年代进行的垃圾回收,发生一次MajorGC至少伴随一次MinorGC,一般比MinorGC速度慢十倍以上。 FullGC:整个堆内存进行的垃圾回收,很多时候是MajorGC 以后就是堆内存结构已经大致的垃圾回收过程。三、对象分配原则1.对象优先分配在Eden区,如果Eden区没有足够的空间时,虚拟机执行一次Minor GC。2.大对象直接进入老年代(大对象是指需要大量连续内存空间的对象)。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝(新生代采用复制算法收集内存)。3.长期存活的对象进入老年代。虚拟机为每个对象定义了一个年龄计数器,如果对象经过了1次Minor GC那么对象会进入Survivor区,之后每经过一次Minor GC那么对象的年龄加1,知道达到阀值对象进入老年区。4.动态判断对象的年龄。如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象可以直接进入老年代。5.空间分配担保。每次进行Minor GC时,JVM会计算Survivor区移至老年区的对象的平均大小,如果这个值大于老年区的剩余值大小则进行一次Full GC,如果小于检查HandlePromotionFailure设置,如果true则只进行Monitor GC,如果false则进行Full GC。四、垃圾收集器作为JVM中的核心之一垃圾收集器,主要完成的功能包括:(1)发现无用信息对象;(2)回收被无用对象占用的内存空间,使该空间可被程序再次使用。所以说我们在实现垃圾收集器的同时就要实现两个算法一个是发现无用的对象第二就是回收该对象的内存。收集器主要分为引用计数器和跟踪收集器两种,Sun JDK中采用跟踪收集器作为GC实现策略。发现无用对象只要的实现算法包括引用计数法和根搜索算法,引用计数法主要是JVM的早期实现方法,因为引用计数无法解决循环引用的问题,所以现在JVM实现的主要是根搜索算法,引用计数法:堆中的每个对象对应一个引用计数器。当每一次创建一个对象并赋给一个变量时,引用计数器置为1。当对象被赋给任意变量时,引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用),引用计数器减1,一旦引用计数器为0,对象就不可用从而可以被回收。 根搜索算法:通过一系列的名为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连(用图论的话来说就是从GC Roots到这个对象不可达)时,则证明此对象是不可用的。目前的收集器主要有三种:串行收集器:使用单线程处理所有垃圾回收工作,因为无需多线程交互,所以效率比较高并行收集器:对年轻代进行并行垃圾回收,因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用并发收集器:可以保证大部分工作都并发进行(应用不停止),垃圾回收只暂停很少的时间,此收集器适合对响应时间要求比较高的中、大规模应用五、垃圾收集器的回收算法Copying算法:算法:复制采用的方式为从根集合扫描出存活的对象,并将找到的存活对象复制到一块新的完全未使用的空间中。 过程: 此算法把内存空间划为两个相等的区域,每次只使用其中一个区域。垃圾回收时,遍历当前使用区域,把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象,因此复制成本比较小,同时复制过去以后还能进行相应的内存整理,不过出现“碎片”问题。当然,此算法的缺点也是很明显的,就是需要两倍内存空间。Mark-Sweep算法: 算法:标记-清除采用的方式为从根集合开始扫描,对存活的对象进行标记,标记完毕后,再扫描整个空间中未标记的对象,并进行回收。 过程: 第一阶段从引用根节点开始标记所有被引用的对象,第二阶段遍历整个堆,把未标记的对象清除。它停止所有工作,收集器从根开始访问每一个活跃的节点,标记它所访问的每一个节点。走过所有引用后,收集就完成了,然后就对堆进行清除(即对堆中的每一个对象进行检查),所有没有标记的对象都作为垃圾回收并返回空闲列表。Mark-Compact算法: 算法:标记阶段与“Mark-Sweep”算法相同,但在清除阶段有所不同。在回收不存活对象所占用的内存空间后,会将其他所有存活对象都往左端空闲的空间进行移动,并更新引用其对象指针。过程:此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段,第一阶段从根节点开始标记所有被引用对象,第二阶段遍历整个堆,把清除未标记对象并且把存活对象“压缩”到堆的其中一块,按顺序排放。此算法避免了“标记-清除”的碎片问题,同时也避免了“复制”算法的空间问题。Sun JDK GC策略:新生代算法实现:Copying,Copying,Copying旧生代算发实现:Mark-Sweep-Compact,Mark –Compact,Mark –Sweep!!六、JvisuaVM 工具如果我们想优化自己的程序,那么我们就必须清楚的了解不同代码程序所消耗的性能多少,作为JDK的一部分,这个工具给我们提供了很大的帮助。这个工具可以在JDK的bin目录下找到,功能很强大,可以注意利用
auto_answer 2019-12-02 01:56:35 0 浏览量 回答数 0

问题

云计算之路-黎明前的黑暗:20130424网站故障经过

博文原文: http://www.cnblogs.com/cmt/archive/2013/04/24/3041368.html 一、背景 4月18日的访问高峰 扛过去之后,我们和阿里云一直在努力寻找问题的真...
cnblogs 2019-12-01 21:13:14 11839 浏览量 回答数 12

回答

在线程中使用 System.Windows.Forms.Timer 是不能触发 Tick 事件的,为什么?如何在线程中使用定时器呢?就看本文介绍。 一. System.Windows.Forms.Timer System.Windows.Forms.Timer 要求要有UI 消息泵, 所以通常只在主线程上使用. System.Windows.Forms.Timer 用于以用户定义的事件间隔触发事件。 Windows 计时器是为单线程环境设计的,其中,UI 线程用于执行处理。 它要求用户代码有一个可用的 UI 消息泵,而且总是在同一个线程中操作,或者将调用封送到另一个线程. 且看MSDN的用法解释: 实现在用户定义的时间间隔引发事件的计时器。此计时器最宜用于 Windows 窗体应用程序中,并且必须在窗口中使用。 二. System.Timers.Timer System.Timers.Timer 组件是基于服务器的计时器,它使您能够指定在应用程序中引发 Elapsed 事件的周期性间隔。 然后可以操控此事件以提供定期处理。例如,假设您有一台关键性服务器,必须每周 7 天、每天 24 小时都保持运行。 可以创建一个使用 Timer 的服务,以定期检查服务器并确保系统开启并在运行。如果系统不响应,则该服务可以尝试重新启动服务器或通知管理员。 基于服务器的 Timer 是为在多线程环境中用于辅助线程而设计的。 服务器计时器可以在线程间移动来处理引发的 Elapsed 事件,这样就可以比 Windows 计时器更精确地按时引发事件。 有关基于服务器的计时器的更多信息,请参见“基于服务器的计时器介绍”。 在 Visual Studio 和 .NET Framework 中有三种计时器控件:基于服务器的计时器(可以在“工具箱”的“组件”选项卡上看到)、基于 Windows 的标准计时器(可以在“工具箱”的“Windows 窗体”选项卡上看到)和线程计时器(只能以编程方式使用)。 基于 Windows 的计时器从 Visual Basic 1.0 版起就存在于该产品中,并且基本上未做改动。该计时器针对在 Windows 窗体应用程序中使用而进行了优化。 基于服务器的计时器是传统的计时器为了在服务器环境上运行而优化后的更新版本。 线程计时器是一种简单的、轻量级计时器,它使用回调方法而不是使用事件,并由线程池线程提供支持。 在 Win32 体系结构中有两种类型的线程:UI 线程和辅助线程。UI 线程绝大多数时间处于空闲状态,等待消息循环中的消息到来。 一旦接收到消息,它们就进行处理并等待下一个消息到来。另外,辅助线程用来执行后台处理而且不使用消息循环。 Windows 计时器和基于服务器的计时器在运行时都使用 Interval 属性。线程计时器的时间间隔在 Timer 构造函数中设置。 计时器的设计目的各不相同,它们的线程处理明确地指出了这一点: 1.Windows 计时器是为单线程环境设计的,其中,UI 线程用于执行处理。Windows 计时器的精度限定为 55 毫秒。 这些传统计时器要求用户代码有一个可用的 UI 消息泵,而且总是在同一个线程中操作,或者将调用封送到另一个线程。对于 COM 组件来说,这样会降低性能。 2.基于服务器的计时器是为在多线程环境下与辅助线程一起使用而设计的。由于它们使用不同的体系结构,因此基于服务器的计时器可能比 Windows 计时器精确得多。 服务器计时器可以在线程之间移动来处理引发的事件。 3.对消息不在线程上发送的方案中,线程计时器是非常有用的。例如,基于 Windows 的计时器依赖于操作系统计时器的支持,如果不在线程上发送消息,与计时器相关的事件将不会发生。 在这种情况下,线程计时器就非常有用。 “答案来源于网络,供您参考” 希望以上信息可以帮到您!
牧明 2019-12-02 02:17:14 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务