Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

编辑 Application Load Balancer 的目标组属性

为您的 Application Load Balancer 创建目标组后，您可以编辑其目标组属性。

取消注册延迟

Elastic Load Balancing 停止将请求发送到正在取消注册的目标。默认情况下，Elastic Load Balancing 在取消注册过程完成前会等待 300 秒，这有助于完成针对目标的进行中的请求。要更改 Elastic Load Balancing 等待的时间，请更新取消注册延迟值。

取消注册的目标的初始状态为 draining。取消注册延迟结束后，取消注册过程完成，目标状态变为 unused。如果目标是 Auto Scaling 组的一部分，便可以将其终止或替换。

如果取消注册的目标没有进行中的请求且没有活动连接，则 Elastic Load Balancing 将立即完成取消注册过程，而不等待取消注册延迟结束。但是，即使目标注销已完成，目标的状态也会显示为 draining，直至注销延迟超时期限过期。超时期限过期后，目标转换为 unused 状态。

如果正在取消注册的目标在取消注册延迟结束前终止连接，客户端将收到 500 级错误响应。

要更新取消注册延迟值，请使用 Amazon CLI

使用带有deregistration_delay.timeout_seconds属性的modify-target-group-attributes命令。

慢启动模式

默认情况下，目标只要注册到目标组并通过了初始运行状况检查，就会开始接收其完整的请求份额。使用慢启动模式可给目标时间进行预热，然后负载均衡器向其发送完整的请求份额。

为目标组启用慢启动后，当目标组认为其目标正常时，其目标会进入慢启动模式。慢启动模式下的目标在配置的慢启动持续时间过去或目标变得不正常时退出慢启动模式。负载均衡器线性增加它可以向慢启动模式下的目标发送的请求数量。在正常目标退出慢启动模式后，负载均衡器可以向它发送完整的请求份额。

要更新慢速启动持续时间值，请使用 Amazon CLI

使用带有slow_start.duration_seconds属性的modify-target-group-attributes命令。

Application Load Balancer 目标组的跨区域负载平衡

负载均衡器的节点将来自客户端的请求分配给已注册目标。启用跨可用区负载均衡后，每个负载均衡器节点会在所有已注册可用区中的已注册目标之间分配流量。禁用跨可用区负载均衡后，每个负载均衡器节点会仅在其可用区中的已注册目标之间分配流量。这可能是因为可用区故障域优先于区域性故障域，从而确保运行状况良好可用区不受运行状况不佳可用区的影响，或者改善整体延迟。

对于应用程序负载均衡器，始终在负载均衡器级别启用跨可用区负载均衡，并且无法关闭。对于目标组，默认设置是使用负载均衡器设置，但您可以通过在目标组级别明确关闭跨可用区负载均衡来覆盖默认设置。

关闭跨可用区负载均衡

您可以随时对应用程序负载均衡器目标组关闭跨可用区负载均衡。

要关闭跨区域负载均衡，请使用 Amazon CLI

使用modify-target-group-attributes命令并将load_balancing.cross_zone.enabled属性设置为false。

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=false

以下为响应示例：

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "false"
        },
    ]
}

启用跨可用区负载均衡

您可以随时对应用程序负载均衡器目标组启用跨可用区负载均衡。目标组级别的跨可用区负载均衡设置会覆盖负载均衡器级别的设置。

要启用跨区域负载均衡，请使用 Amazon CLI

使用modify-target-group-attributes命令并将load_balancing.cross_zone.enabled属性设置为true。

aws elbv2 modify-target-group-attributes --target-group-arn my-targetgroup-arn --attributes Key=load_balancing.cross_zone.enabled,Value=true

以下为响应示例：

{
    "Attributes": [
        {
            "Key": "load_balancing.cross_zone.enabled",
            "Value": "true"
        },
    ]
}

自动目标权重 (ATW)

Automation Target Weights (ATW) 持续监控运行应用程序的目标，检测明显的性能偏差，即异常。ATW通过实时数据异常检测，能够动态调整路由到目标的流量。

自动目标权重 (ATW) 会自动对您账户中的每个 Application Load Balancer 执行异常检测。识别出异常目标后，ATW可以自动尝试通过减少其路由的流量来稳定这些目标，这被称为异常缓解。ATW持续优化流量分布，以最大限度地提高每个目标的成功率，同时最大限度地降低目标组的失败率。

异常检测

ATW异常检测会监视任何表现出与目标组中其他目标行为明显偏差的目标。这些偏差称为异常，是通过将一个目标的误差百分比与目标组中其他目标的误差百分比进行比较来确定的。这些错误既可以是连接错误，也可以是HTTP错误代码。因此，报告比同行高得多的目标被视为异常。

异常检测要求目标组中至少有三个健康目标。当目标注册到目标组时，它必须先通过运行状况检查才能开始接收流量。目标接收目标后，ATW开始监视目标并持续发布异常结果。对于没有异常的目标，异常结果为。normal对于存在异常的目标，异常结果为。anomalous

ATW异常检测独立于目标群体的健康检查。目标可以通过所有目标组的健康检查，但由于错误率升高，仍会被标记为异常。目标变为异常不会影响其目标组的健康检查状态。

异常检测状态

ATW持续发布其对目标执行的异常检测的状态。您可以使用 Amazon Web Services Management Console 或随时查看当前状态 Amazon CLI。

要查看异常检测结果，请使用 Amazon CLI

使用将Include.member.N属性值设置为的describe-target-health命令AnomalyDetection。

异常缓解

ATW异常缓解会自动将流量从异常目标上移开，从而使他们有机会恢复。

开启ATW异常缓解功能

您可以随时开启异常缓解功能。

要开启异常缓解功能，请使用 Amazon CLI

使用带有load_balancing.algorithm.anomaly_mitigation属性的modify-target-group-attributes命令。

异常缓解状态

无论ATW何时对目标执行缓解，都可以使用 Amazon Web Services Management Console 或随时查看当前状态 Amazon CLI。

要查看异常缓解状态，请使用 Amazon CLI

使用将Include.member.N属性值设置为的describe-target-health命令AnomalyDetection。

Application Load Balancer 的粘性会话

默认情况下，Application Load Balancer 会根据选定负载均衡算法将每项请求单独路由到已注册的目标。但是，您可以使用粘性会话功能（也称为会话关联），使负载均衡器能够将用户会话绑定到特定的目标。这可确保在会话期间将来自用户的所有请求发送到同一目标中。对于维护状态信息以便向客户端提供持续体验的服务器来说，此功能很有用。要使用粘性会话，客户端必须支持 Cookie。

Application Load Balancer 支持基于持续时间的 Cookie 和基于应用程序的 Cookie。粘性会话会在目标组级别启用。您可以在目标组中组合使用基于持续时间的粘性、基于应用程序的粘性以及非粘性。

管理粘性会话的关键是确定负载均衡器一致地将用户请求路由到同一目标的时间长短。如果您的应用程序拥有自己的会话 Cookie，则可以使用基于应用程序的粘性，且负载均衡器会话 Cookie 将会遵循应用程序会话 Cookie 指定的持续时间。如果您的应用程序没有自己的会话 Cookie，则可以使用基于持续时间的粘性来生成具有您指定持续时间的负载均衡器会话 Cookie。

负载均衡器生成的 Cookie 内容使用轮换密钥加密。您无法解密或修改负载均衡器生成的 Cookie。

对于这两种粘性类型，Application Load Balancer 将重置每次请求后生成的 Cookie 的过期期限。如果 Cookie 过期，会话将不再具有粘性，客户端应该从 Cookie 存放区删除 Cookie。

基于持续时间的粘性

基于持续时间的粘性使用负载均衡器生成的 Cookie (AWSALB) 将请求路由到目标组中的同一目标。Cookie 用于将会话映射到目标。如果您的应用程序没有自己的会话 Cookie，您可以指定自己的粘性持续时间，并管理负载均衡器一致地将用户请求路由到同一目标的时间长短。

当负载均衡器第一次收到来自客户端的请求时，它会（根据选定算法）将请求路由到目标并生成名为 AWSALB 的 Cookie。它还会对选定目标的有关信息进行编码，加密 Cookie，并在对客户端的响应中包含 Cookie。负载平衡器生成的 Cookie 具有自身的 7 天到期时间，且不可配置。

在后续请求中，客户端应包含 AWSALB Cookie。当负载均衡器收到来自包含 Cookie 的客户端的请求时，它会检测到该请求并将请求路由到同一目标。如果 cookie 存在但无法解码，或者它指的是已取消注册或不正常的目标，则负载均衡器会选择一个新目标并使用有关新目标的信息更新 cookie。

对于跨域资源共享 (CORS) 请求，某些浏览器SameSite=None; Secure需要启用粘性。为了支持这些浏览器，负载均衡器始终会生成第二个粘性 cookieAWSALBCORS，其中包含与原始粘性 cookie 相同的信息以及属性。SameSite客户会收到两个 Cookie，包括非CORS请求。

要启用基于持续时间的粘性，请使用 Amazon CLI

使用带有stickiness.enabled和stickiness.lb_cookie.duration_seconds属性的modify-target-group-attributes命令。

使用以下命令启用基于持续时间的粘性。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=time-in-seconds

您的输出应类似于以下示例。

     {     
        "Attributes": [
           ...
            {
                 "Key": "stickiness.enabled",
                 "Value": "true"
              },           
              {
                  "Key": "stickiness.lb_cookie.duration_seconds",
                  "Value": "86500"
              
              },
           ...
          ]
      }           

基于应用程序的粘性

基于应用程序的粘性可以让您灵活地为客户端目标粘性设置自己的标准。启用基于应用程序的粘性时，负载均衡器会根据选定算法将第一个请求路由到目标组内的目标。为启用粘性，目标应设置与负载均衡器上配置的 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，依此类推。

要启用基于应用程序的粘性，请使用 Amazon CLI

使用具有以下属性的modify-target-group-attributes命令：

使用以下命令启用基于应用程序的粘性。

aws elbv2 modify-target-group-attributes --target-group-arn ARN --attributes Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie Key=stickiness.app_cookie.cookie_name,Value=my-cookie-name Key=stickiness.app_cookie.duration_seconds,Value=time-in-seconds

您的输出应类似于以下示例。

 
       {
            "Attributes": [
                ...
                {
                    "Key": "stickiness.enabled",
                    "Value": "true"
                },
                {
                    "Key": "stickiness.app_cookie.cookie_name",
                    "Value": "MyCookie"
                },
                {
                    "Key": "stickiness.type",
                    "Value": "app_cookie"
                },
                {
                    "Key": "stickiness.app_cookie.duration_seconds",
                    "Value": "86500"
                },
                ...
            ]
        }  
            
            

手动再平衡

向上扩展时，如果目标数量大幅度增加，则可能由于粘性而导致负载分配不均。在这种情况下，您可以使用以下两种方式再平衡目标上的负载：