本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
编辑应用程序负载均衡器的目标组属性
为应用程序负载均衡器创建目标组后，您可以编辑其目标组属性。
取消注册延迟
ELB 停止向正在取消注册的目标发送请求。默认情况下，ELB 在完成注销过程之前会等待 300 秒，这可以帮助完成向目标发出的飞行中请求。要更改 ELB 等待的时间，请更新注销延迟值。
取消注册的目标的初始状态为 draining。取消注册延迟结束后，取消注册过程完成，目标状态变为 unused。如果目标是 Auto Scaling 组的一部分，便可以将其终止或替换。
如果注销目标没有正在进行的请求，也没有活动连接，ELB 会立即完成注销过程，无需等待注销延迟过去。但是，即使目标注销已完成，目标的状态也会显示为 draining，直至注销延迟超时期限过期。超时期限过期后，目标转换为 unused 状态。
如果正在取消注册的目标在取消注册延迟结束前终止连接，客户端将收到 500 级错误响应。
路由算法
路由算法是在确定哪些目标将接收请求时负载均衡器使用的方法。默认情况下，使用轮询路由算法在目标组级别路由请求。还可以根据应用程序的需求使用最少未完成的请求和加权随机路由算法。一个目标组一次只能有一个活动的路由算法，但可以根据需要随时更新路由算法。
如果启用粘性会话，则所选的路由算法将用于初始目标选择。来自同一客户端的未来请求将被转发到同一目标，从而绕过所选的路由算法。如果您启用了目标优化器，则路由算法只能是循环算法。
轮询
-
轮询路由算法按顺序将请求均匀地路由到目标组中运行状况良好的目标。
-
当收到的请求复杂度相似、已注册目标的处理能力相似，或者您需要在目标之间平均分配请求时，通常使用此算法。
最少未完成请求
-
最少未完成的请求路由算法将请求路由到正在进行的请求数最少的目标。
-
当收到的请求复杂度不同、已注册目标的处理能力不同时，通常使用此算法。
-
当支持 HTTP/2 的负载均衡器使用仅支持 HTTP/1.1 的目标时，它会将请求转换为多个 HTTP/1.1 请求。在此配置中，最少未完成的请求算法会将每个 HTTP/2 请求视为多个请求。
-
使用时 WebSockets，将使用未完成请求数最少算法选择目标。选择该目标后，负载均衡器将创建与该目标的连接并通过此连接发送所有消息。
-
最少未完成的请求路由算法不能与慢启动模式一起使用。
加权随机
-
加权随机路由算法以随机顺序在目标组中运行状况良好的目标之间均匀路由请求。
-
此算法支持自动目标权重（ATW）异常缓解。
-
加权随机路由算法不能与慢启动模式一起使用。
-
加权随机路由算法不能与粘性会话一起使用。
慢启动模式
默认情况下，目标只要注册到目标组并通过了初始运行状况检查，就会开始接收其完整的请求份额。使用慢启动模式可给目标时间进行预热，然后负载均衡器向其发送完整的请求份额。
为目标组启用慢启动后，当目标组认为其目标正常时，其目标会进入慢启动模式。慢启动模式下的目标在配置的慢启动持续时间过去或目标变得不正常时退出慢启动模式。负载均衡器线性增加它可以向慢启动模式下的目标发送的请求数量。在正常目标退出慢启动模式后，负载均衡器可以向它发送完整的请求份额。
注意事项
-
为目标组启用慢启动之后，注册到目标组的正常目标不会进入慢启动模式。
-
当您为空的目标组启用慢启动，然后使用单一注册操作注册目标时，这些目标不会进入慢启动模式。仅当至少有一个正常目标未处于慢启动模式时，新注册的目标才会进入慢启动模式。
-
如果您在慢启动模式下取消注册目标，目标将退出慢启动模式。如果您再次注册同一目标，则当目标组认为该目标正常时，它将进入慢启动模式。
-
如果处于慢启动模式的目标变得不正常，则该目标将退出慢启动模式。当目标变得正常时，它将再次进入慢启动模式。
-
使用最少未完成的请求或加权随机路由算法时，无法启用慢启动模式。
运行状况设置
默认情况下，应用程序负载均衡器会监控目标的运行状况，并将请求路由到运行正常的目标。但如果负载均衡器没有足够运行正常的目标，则会自动将流量发送到所有已注册的目标（失效时开放）。您可以修改目标组的运行状况设置，从而定义 DNS 故障转移和路由失效转移的阈值。有关更多信息，请参阅 目标组运行状况。
跨可用区负载均衡
负载均衡器的节点将来自客户端的请求分配给已注册目标。启用跨可用区负载均衡后，每个负载均衡器节点会在所有已注册可用区中的已注册目标之间分配流量。禁用跨可用区负载均衡后，每个负载均衡器节点会仅在其可用区中的已注册目标之间分配流量。这可能是因为可用区故障域优先于区域性故障域，从而确保运行状况良好可用区不受运行状况不佳可用区的影响，或者改善整体延迟。
对于应用程序负载均衡器，始终在负载均衡器级别启用跨可用区负载均衡，并且无法关闭。对于目标组，默认设置是使用负载均衡器设置，但您可以通过在目标组级别明确关闭跨可用区负载均衡来覆盖默认设置。
注意事项
-
当跨可用区负载均衡关闭时，不支持目标粘性。
-
当跨可用区负载均衡关闭时，不支持 Lambda 函数作为目标。
-
如果任何目标的参数
AvailabilityZone设置为all，则尝试通过ModifyTargetGroupAttributesAPI 关闭跨可用区负载均衡会导致错误。 -
注册目标时，
AvailabilityZone参数是必需的。仅当跨可用区负载均衡关闭时，才允许特定可用区值。否则，该参数将被忽略并视为all。
最佳实践
-
针对每个目标组，在您预期利用的所有可用区内规划足够的目标容量。如果无法为所有参与的可用区规划足够的容量，我们建议您继续启用跨可用区负载均衡。
-
使用多个目标组配置应用程序负载均衡器时，请确保所有目标组都参与配置区域内的相同可用区。这是为了避免在跨可用区负载均衡关闭时可用区为空，因为这会对进入空可用区的所有 HTTP 请求触发 503 错误。
-
请避免创建空子网。应用程序负载均衡器通过 DNS 公开空子网的区域 IP 地址，这会对 HTTP 请求触发 503 错误。
-
在某些情况下，关闭了跨可用区负载均衡的目标组在每个可用区都有足够的计划目标容量，但可用区中的所有目标都变得不正常。当至少有一个目标组包含所有运行状况不佳的目标时，将从 DNS 中删除负载均衡器节点的 IP 地址。在目标组拥有至少一个运行状况良好的目标后，IP 地址将恢复到 DNS。
关闭跨可用区负载均衡
您可以随时对应用程序负载均衡器目标组关闭跨可用区负载均衡。
启用跨可用区负载均衡
您可以随时对应用程序负载均衡器目标组启用跨可用区负载均衡。目标组级别的跨可用区负载均衡设置会覆盖负载均衡器级别的设置。
自动目标权重（ATW）
自动目标权重（ATW）持续监控运行您的应用程序的目标，检测显著性能偏差（称为异常）。ATW 能够通过实时数据异常检测来动态调整路由到目标的流量。
自动目标权重（ATW）会自动对您账户中的每个应用程序负载均衡器执行异常检测。当发现异常目标时，ATW 可以自动尝试通过减少路由的流量来稳定这些目标，这称为异常缓解。ATW 不断优化流量分配，以最大限度地提高每个目标的成功率，同时最大限度地降低目标组的失败率。
注意事项：
-
异常检测目前会监控来自您的目标的 HTTP 5xx 响应代码以及与目标的连接失败。异常检测始终处于开启状态，不能关闭。
-
使用 Lambda 作为目标时，不支持 ATW。
异常检测
ATW 异常检测会监控任何与目标组中其他目标的行为存在显著偏差的目标。这些偏差称为异常，通过比较一个目标的百分比误差与目标组中其他目标的百分比误差来确定。这些错误既可能是连接错误，也可能是 HTTP 错误代码。报告值明显高于对等目标的目标则被视为异常。
异常检测要求目标组中至少有三个运行状况良好的目标。当目标注册到目标组时，必须通过运行状况检查后才能开始接收流量。目标开始接收流量后，ATW 将开始监控目标并持续发布异常检测结果。对于没有异常的目标，异常结果为 normal。对于存在异常的目标，异常结果为 anomalous。
ATW 异常检测独立于目标组运行状况检查。目标可以通过所有目标组运行状况检查，但仍会因错误率升高而被标记为异常。目标变为异常不会影响其目标组运行状况检查状态。
异常检测状态
您可以查看当前的异常检测状态。有以下可能值：
-
normal：未检测到异常。 -
anomalous：检测到异常。
异常缓解
ATW 异常缓解会自动将流量从异常目标路由出去，为其提供恢复的机会。
要求
ATW 的异常缓解功能仅在使用加权随机路由算法时可用。
缓解期间：
-
ATW 会定期调整路由到异常目标的流量。目前，周期为每五秒一次。
-
ATW 会将路由到异常目标的流量减少到执行异常缓解所需的最低量。
-
不再被检测为异常的目标将逐渐获得更多路由到它们的流量，直到它们达到与目标组中其他正常目标的同等水平。
缓解状态
您可以检查 ATW 是否正在对目标执行缓解。有以下可能值：
yes：正在进行缓解。no：未进行缓解。
粘性会话
默认情况下，Application Load Balancer 会根据选定负载均衡算法将每项请求单独路由到已注册的目标。但是，您可以使用粘性会话功能（也称为会话关联），使负载均衡器能够将用户会话绑定到特定的目标。这可确保在会话期间将来自用户的所有请求发送到同一目标中。对于维护状态信息以便向客户端提供持续体验的服务器来说，此功能很有用。要使用粘性会话，客户端必须支持 Cookie。
Application Load Balancer 支持基于持续时间的 Cookie 和基于应用程序的 Cookie。粘性会话会在目标组级别启用。您可以在目标组中组合使用基于持续时间的粘性、基于应用程序的粘性以及非粘性。
管理粘性会话的关键是确定负载均衡器一致地将用户请求路由到同一目标的时间长短。如果您的应用程序拥有自己的会话 Cookie，则可以使用基于应用程序的粘性，且负载均衡器会话 Cookie 将会遵循应用程序会话 Cookie 指定的持续时间。如果您的应用程序没有自己的会话 Cookie，则可以使用基于持续时间的粘性来生成具有您指定持续时间的负载均衡器会话 Cookie。
负载均衡器生成的 Cookie 内容使用轮换密钥加密。无法解密或修改负载均衡器生成的 Cookie。
对于这两种粘性类型，Application Load Balancer 将重置每次请求后生成的 Cookie 的过期期限。如果 Cookie 过期，会话将不再具有粘性，客户端应该从 Cookie 存放区删除 Cookie。
要求
-
HTTP/HTTPS 负载均衡器。
-
每个可用区内至少有一个运行状况良好的实例。
注意事项
-
如果跨可用区负载均衡禁用，则不支持粘滞会话。禁用跨可用区负载均衡期间启用粘性会话的尝试将会失败。
-
对于基于应用程序的 Cookie，每个目标组必须单独指定 Cookie 名称。但是，对于基于持续时间的 Cookie，所有目标组将使用
AWSALB作为唯一的名称。 -
如果您使用的是多层 Application Load Balancer，则可以使用基于应用程序的 Cookie 在所有层启用粘性会话。但是，如果使用基于持续时间的 Cookie，您就只能在一个层上启用粘性会话，因为
AWSALB是唯一可用的名称。 -
如果应用程序负载均衡器同时收到
AWSALBCORS和AWSALB基于持续时间的粘性 Cookie，则AWSALBCORS中的值将优先。 -
基于应用程序的粘性不能与加权目标组结合使用。
-
如果您具有一个包含多个目标组的转发操作，并且一个或多个目标组已启用了粘性会话，则必须在目标组级别启用粘性。
-
WebSocket 连接本质上是粘性的。如果客户端请求升级连接 WebSockets，则返回接受连接升级的 HTTP 101 状态码的目标就是 WebSockets连接中使用的目标。 WebSockets 升级完成后，将不使用基于 Cookie 的粘性。
-
Application Load Balancer 使用 Cookie 标头中的
Expires属性而不是Max-Age属性。 -
Application Load Balancer 不支持 URL 编码的 Cookie 值。
-
如果应用程序负载均衡器在目标因注销而耗尽时收到新请求，则该请求将被路由到运行正常的目标。
-
如果启用了目标优化器，则不支持粘性会话。
基于持续时间的粘性
基于持续时间的粘性使用负载均衡器生成的 Cookie (AWSALB) 将请求路由到目标组中的同一目标。Cookie 用于将会话映射到目标。如果您的应用程序没有自己的会话 Cookie，您可以指定自己的粘性持续时间，并管理负载均衡器一致地将用户请求路由到同一目标的时间长短。
当负载均衡器第一次收到来自客户端的请求时，它会（根据选定算法）将请求路由到目标并生成名为 AWSALB 的 Cookie。它还会对选定目标的有关信息进行编码，加密 Cookie，并在对客户端的响应中包含 Cookie。负载平衡器生成的 Cookie 具有自身的 7 天到期时间，且不可配置。
在后续请求中，客户端应包含 AWSALB Cookie。当负载均衡器收到来自包含 Cookie 的客户端的请求时，它会检测到该请求并将请求路由到同一目标。如果 Cookie 存在但无法解码，或者指向某个已注销或运行不正常的目标，则负载均衡器会选择一个新目标并使用有关新目标的信息来更新 Cookie。
对于跨源资源共享（CORS）请求，某些浏览器需要 SameSite=None; Secure 来启用粘性。为了支持这些浏览器，负载均衡器始终会生成第二个粘性 Cookie AWSALBCORS（其中包含与原始粘性 Cookie 相同的信息）和 SameSite 属性。客户端会接收两种 cookie，包括非 CORS 请求。
基于应用程序的粘性
基于应用程序的粘性可以让您灵活地为客户端目标粘性设置自己的标准。启用基于应用程序的粘性时，负载均衡器会根据选定算法将第一个请求路由到目标组内的目标。为启用粘性，目标应设置与负载均衡器上配置的 Cookie 匹配的自定义应用程序 Cookie。此自定义 Cookie 可包含应用程序所需的任何 Cookie 属性。
当 Application Load Balancer 收到来自目标的自定义应用程序 Cookie 时，它会自动生成新加密的应用程序 Cookie，以捕获粘性信息。此负载均衡器生成的应用程序 Cookie 可为每个启用基于应用程序的粘性的目标组捕获粘性信息。
负载均衡器生成的应用程序 Cookie 不会复制目标设置的自定义 Cookie 的属性。它自己的过期期限为 7 天，这是不可配置的。在对客户端的响应中，Application Load Balancer 仅验证在目标组级别配置的自定义 Cookie 的名称，而不验证自定义 Cookie 的值或过期属性。只要名称匹配，负载均衡器即会发送 Cookie、目标设置的自定义 Cookie 以及负载均衡器生成的应用程序 Cookie，来响应客户端。
在后续请求中，客户端必须将两个 Cookie 发送回以保持粘性。负载均衡器会解密应用程序 Cookie，并检查配置的粘性持续时间是否仍然有效。然后，它将使用 Cookie 中的信息将请求发送到目标组中的同一目标，以保持粘性。负载均衡器还会将自定义应用程序 Cookie 代理到目标，而不检查或修改它。在后续响应中，会对在负载均衡器上配置的负载均衡器生成的应用程序 Cookie 的到期期限和粘性持续时间进行重置。为了保持客户端和目标之间的粘性，Cookie 的到期期限和粘性持续时间不会消失。
如果目标失败或者目标运行状况不佳，负载均衡器会停止将请求路由到该目标，并根据选定负载均衡算法来选择新的运行状况良好的目标。现在，负载均衡器将会话视为正在“附加”到新的正常运行目标，并继续将请求路由至新的正常运行目标，即使之前失败的目标已恢复正常运行。
对于跨源资源共享 (CORS) 请求，只有当用户代理版本为 Chromium80 或更高版本时，负载均衡器才会将 SameSite=None; Secure 属性添加到负载均衡器生成的应用程序 Cookie 来启用粘性。
由于大多数浏览器将 Cookie 的大小限制为 4K，因此负载均衡器会将大于 4K 的应用程序 Cookie 分片为多个 Cookie。Application Load Balancer 支持最大 16K 的 Cookie，因此最多可以创建 4 个分片发送给客户端。客户端看到的应用程序 Cookie 名称以 “AWSALBAPP-” 开头，并包含一个片段编号。例如，如果 Cookie 大小为 0-4K，则客户端会看到 AWSALBAPP -0。如果 cookie 大小为 4-8k，则客户端会看到 AWSALBAPP -0 和- AWSALBAPP 1，依此类推。
手动再平衡
向上扩展时，如果目标数量大幅度增加，则可能由于粘性而导致负载分配不均。在这种情况下，您可以使用以下两种方式再平衡目标上的负载：
-
将应用程序生成的 Cookie 过期期限设置在当前日期和时间之前。这样可以阻止客户端将 Cookie 发送到应用程序负载均衡器，后者将重启建立粘性的过程。
-
为负载均衡器基于应用程序的粘性配置设置一个较短的持续时间，例如 1 秒。这样将强制应用程序负载均衡器重新建立粘性，即使目标设置的 Cookie 尚未过期。