# 为函数配置预置并发 在 Lambda 中，[并发](lambda-concurrency.md)指您的函数当前正在进行的请求数。有两种类型的并发控件可用： + 预留并发 – 这将设置分配给您的函数的最大和最小并发实例数。当一个函数有预留并发时，任何其他函数都不可以使用该并发。对于确保最关键的函数始终具有足够的并发性来处理传入请求，预留并发非常有用。此外，预留并发可用于限制并发，以防止下游资源（如数据库连接）不堪重负。预留并发既充当下限，也充当上限，它专门为您的函数预留指定的容量，同时也防止其超出该限制扩展。为函数配置预留并发不产生任何额外费用。 + 预置并发 – 指分配给函数的预初始化执行环境的数量。这些执行环境已准备就绪，可以立即响应传入的函数请求。预置并发有助于减少函数的冷启动延迟，旨在使函数具有两位数毫秒的响应时间。通常，交互式工作负载从该功能中获益最大。这些是用户发起请求的应用程序（例如 Web 和移动应用程序），并且对延迟最敏感。异步工作负载（例如数据处理管线）经常对延迟不太敏感，因此通常不需要预置并发。配置预置并发会让您的 AWS 账户 产生额外费用。 本主题详细介绍了如何管理和配置预置并发。有关这两种并发控制的概念概述，请参阅[预留并发和预置并发](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)。有关配置预留并发的更多信息，请参阅[为函数配置预留并发](configuration-concurrency.md)。 **注意** 关联到 Amazon MQ 事件源映射的 Lambda 函数具有默认的最大并发数。对于 Apache Active MQ，最大并发实例数为 5。对于 Rabbit MQ，最大并发实例数为 1。为函数设置预留或预调配的并发不会更改这些限制。要在使用 Amazon MQ 时请求增加默认的最大并发数，请联系 支持。 **Topics** + [配置预配置并发](#configuring-provisioned-concurrency) + [准确估计函数所需的预置并发](#estimating-provisioned-concurrency) + [使用预置并发时优化函数代码](#optimizing-latency) + [使用环境变量查看和控制预置并发行为](#pc-environment-variables) + [了解使用预置并发的日志记录和计费行为](#pc-logging-behavior) + [使用 Application Auto Scaling 自动执行预置并发管理](#managing-provisioned-concurency) ## 配置预配置并发 您可以使用 Lambda 控制台或 Lambda API 为函数配置预置并发设置。 **要为函数分配预置并发（控制台）** 1. 打开 Lamba 控制台的[函数页面](https://console.aws.amazon.com/lambda/home#/functions)。 1. 选择要为其分配预置并发的函数。 1. 选择 **Configuration**（配置），然后选择 **Concurrency**（并发）。 1. 在 **Provisioned concurrency configurations（预配置并发配置）**下，选择 **Add configuration（添加配置）**。 1. 选择限定符类型以及别名或版本。 **注意** 您不能将预置并发与任何函数的 \$1LATEST 版本一起使用。 如果函数具有事件源，请确保该事件源指向正确的函数别名或版本。否则，您的函数将不会使用预置并发环境。 1. 在**预置并发**下输入一个数字。 1. 选择**保存**。 您最多可以在账户中配置的单位数量为**非预留账户并发**减去 100。剩余 100 个单位的并发可用于不会使用预留并发的函数。例如，如果您的账户的并发限制为 1000，并且您没有为任何其他函数分配任何预留或预置并发，则可以为单个函数配置最多 900 个单位的预置并发。 ![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/provisioned-concurrency-over-limit.png) 为函数配置预置并发会影响可用于其他函数的并发池。例如，如果您为 `function-a` 配置 100 个单位的预置并发，则您账户中的其他函数必须共享剩余的 900 个单位的并发。即使 `function-a` 不使用所有 100 个单位的预置并发也是如此。 可以为同一函数同时分配预留并发和预置并发。在这种情况下，预置并发数不能超过预留并发数。 此限制也适用于函数版本。您可以分配给特定函数版本的最大预置并发数等于该函数的预留并发减去其他函数版本上配置的预置并发。 要使用 Lambda API 配置预置并发，请使用以下 API 操作： + [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html) + [GetProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html) + [ListProvisionedConcurrencyConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html) + [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html) 例如，要使用 AWS Command Line Interface（CLI）配置预置并发，请使用 `put-provisioned-concurrency-config` 命令。以下命令将为名为 `my-function` 的 `BLUE` 别名分配 100 个单位的预置并发： ``` aws lambda put-provisioned-concurrency-config --function-name my-function \ --qualifier BLUE \ --provisioned-concurrent-executions 100 ``` 您应该会看到类似如下输出： ``` { "Requested ProvisionedConcurrentExecutions": 100, "Allocated ProvisionedConcurrentExecutions": 0, "Status": "IN_PROGRESS", "LastModified": "2023-01-21T11:30:00+0000" } ``` ## 准确估计函数所需的预置并发 您可以使用 [CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)查看任何活动函数的并发指标。具体而言，`ConcurrentExecutions` 指标显示了您账户中函数的并发调用数。 ![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png) 前面的图表显示，在给定的任何时间，此函数平均处理 5 到 10 个并发请求，峰值为 20 个请求。假设您的账户中还有许多其他函数。**如果此函数对您的应用程序至关重要，并且您的每次调用都需要低延迟响应**，请配置至少 20 个单位的预置并发。 请注意，您也可以使用以下公式[计算并发数](https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency)： ``` Concurrency = (average requests per second) * (average request duration in seconds) ``` 要估计您需要的并发数，请将每秒的平均请求数与平均请求持续时间（以秒为单位）相乘。您可以使用 `Invocation` 指标估算每秒的平均请求数，并使用 `Duration` 指标估计平均请求持续时间（以秒为单位）。 对于配置预置并发，Lambda 建议在函数通常需要的并发的基础上添加 10% 的浮动。例如，如果函数通常在出现 200 个并发请求时达到峰值，请将预置并发设置为 220（200 个并发请求 \$1 10% = 220 个预置并发）。 ## 使用预置并发时优化函数代码 如果您使用预置并发，则请考虑重构函数代码以优化实现低延迟。对于使用预置并发的函数，Lambda 会在分配期间运行任何初始化代码（例如加载库和实例化客户端）。因此，建议将尽可能多的初始化放在主函数处理程序之外，以避免影响实际函数调用期间的延迟。相比之下，如果您在主处理程序代码中初始化库或实例化客户端，则意味着您的函数必须在每次调用时运行该代码（无论您是否使用预置并发，都会发生这种情况）。 对于按需调用，每次函数出现冷启动时，Lambda 可能需要重新运行您的初始化代码。对于此类函数，您可以选择将特定功能的初始化推迟到函数需要该功能的时候。例如，请为 Lambda 处理程序考虑以下控制流： ``` def handler(event, context): ... if ( some_condition ): // Initialize CLIENT_A to perform a task else: // Do nothing ``` 在前面的示例中，开发人员没有在主处理程序之外初始化 `CLIENT_A`，而是在 `if` 语句中对其进行初始化。这样一来，Lambda 只有在 `some_condition` 得到满足时才会运行此代码。如果您在主处理程序之外初始化 `CLIENT_A`，Lambda 会在每次冷启动时运行该代码。这可能会增加总体延迟。 您可以通过向函数添加 X-Ray 监控，来测量随着 Lambda 纵向扩展的冷启动。使用预置并发的函数不会表现出冷启动行为，因为执行环境是在调用之前准备好的。但是，预置并发必须应用于函数的[特定版本或别名](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)，而不是 \$1LATEST 版本。如果继续看到冷启动行为，则请确保您调用的是配置了预置并发的别名版本。 ## 使用环境变量查看和控制预置并发行为 函数可能会用尽其所有预置并发。Lambda 使用按需实例来处理任何过多流量。为了确定 Lambda 将哪种类型的初始化用于特定环境，请检查 `AWS_LAMBDA_INITIALIZATION_TYPE` 环境变量的值。此变量可能有两个值：`provisioned-concurrency` 和 `on-demand`。`AWS_LAMBDA_INITIALIZATION_TYPE` 的值是不可变的，并且在环境的整个生命周期中保持不变。要查看函数代码中环境变量的值，请参阅 [检索 Lambda 环境变量](configuration-envvars.md#retrieve-environment-variables)。 如果使用的是 .NET 8 运行时系统，则可以配置 `AWS_LAMBDA_DOTNET_PREJIT` 环境变量以改善函数的延迟，即使函数不使用预置并发。.NET 运行时系统会延时编译和初始化代码首次调用的每个库。因此，首次调用 Lambda 函数的时间可能比后续调用的时间更长。要缓解此问题，可以为 `AWS_LAMBDA_DOTNET_PREJIT` 从以下三个值中任选一个： + `ProvisionedConcurrency`：Lambda 会使用预置并发为所有环境执行提前 JIT 编译。这是默认值。 + `Always`：Lambda 会为每个环境执行提前 JIT 编译，即使函数不使用预置并发也是如此。 + `Never`：Lambda 会为所有环境禁用提前 JIT 编译。 ## 了解使用预置并发的日志记录和计费行为 对于预置并发环境，函数的初始化代码在分配期间定期运行一次，因为 Lambda 会回收环境实例。即使环境实例从未处理过请求，Lambda 也会对初始化进行计费。预配置并发连续运行，并且与初始化和调用成本分开计费。有关更多详细信息，请参阅 [AWS Lambda 定价](https://aws.amazon.com/lambda/pricing/)。 当您配置具有预置并发的 Lambda 函数时，Lambda 会预先初始化该执行环境，使其在调用请求之前可用。每次初始化环境时，Lambda 都会以 JSON 日志记录格式将函数的[初始化持续时间字段](lambda-runtime-environment.md#runtimes-lifecycle-ib)记录在 [platform-initReport](telemetry-schema-reference.md#platform-initReport) 日志事件中。要查看此日志事件，请将您的 [JSON 日志级别](monitoring-cloudwatchlogs-logformat.md)至少配置为 `INFO`。您还可以使用[遥测 API](telemetry-api-reference.md) 来使用报告“初始化持续时间”字段的平台事件。 ## 使用 Application Auto Scaling 自动执行预置并发管理 您可以使用 Application Auto Scaling 根据计划或基于利用率管理预置并发。如果函数的流量模式是可预测的，请使用计划扩展。如果您希望函数保持特定利用率，请使用目标跟踪扩展策略。 **注意** 如果您使用 Application Auto Scaling 来管理函数的预调配并发，请确保先[配置初始预调配并发值](#configuring-provisioned-concurrency)。如果您的函数没有初始预调配并发值，则 Application Auto Scaling 可能无法正确处理函数扩展。 ### 计划扩展 借助 Application Auto Scaling，您可以按照可预测的负载变化来设置自己的扩展计划。有关更多信息和示例，请参阅《Application Auto Scaling 用户指南》中的 [Application Auto Scaling 的计划扩展](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)，以及在 AWS 计算博客上的[为经常出现的峰值使用情况计划 AWS Lambda 预置并发](https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/)。 ### 目标跟踪 借助目标跟踪，Application Auto Scaling 可根据您定义扩展策略的方式创建和管理一组 CloudWatch 警报。当这些警报激活时，Application Auto Scaling 会使用预置并发自动调整分配的环境数量。针对流量模式不可预测的应用程序，使用目标跟踪。 要使用目标跟踪扩展预置并发，请使用 `RegisterScalableTarget` 和 `PutScalingPolicy` Application Auto Scaling API 操作。例如，如果您使用的是 AWS Command Line Interface（CLI），请按照以下步骤操作： 1. 将函数的别名注册为扩展目标。以下示例注册名为 `my-function` 的函数的 BLUE 别名： ``` aws application-autoscaling register-scalable-target --service-namespace lambda \ --resource-id function:my-function:BLUE --min-capacity 1 --max-capacity 100 \ --scalable-dimension lambda:function:ProvisionedConcurrency ``` 1. 将扩展策略应用于目标。以下示例配置 Application Auto Scaling，用于调节别名的预置并发配置，让利用率接近 70%，但也可以应用 10% 到 90% 之间的任意值。 ``` aws application-autoscaling put-scaling-policy \ --service-namespace lambda \ --scalable-dimension lambda:function:ProvisionedConcurrency \ --resource-id function:my-function:BLUE \ --policy-name my-policy \ --policy-type TargetTrackingScaling \ --target-tracking-scaling-policy-configuration '{ "TargetValue": 0.7, "PredefinedMetricSpecification": { "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" }}' ``` 应看到类似如下内容的输出： ``` { "PolicyARN": "arn:aws:autoscaling:us-east-2:123456789012:scalingPolicy:12266dbb-1524-xmpl-a64e-9a0a34b996fa:resource/lambda/function:my-function:BLUE:policyName/my-policy", "Alarms": [ { "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7", "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmHigh-aed0e274-xmpl-40fe-8cba-2e78f000c0a7" }, { "AlarmName": "TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66", "AlarmARN": "arn:aws:cloudwatch:us-east-2:123456789012:alarm:TargetTracking-function:my-function:BLUE-AlarmLow-7e1a928e-xmpl-4d2b-8c01-782321bc6f66" } ] } ``` Application Auto Scaling 会在 CloudWatch 中创建两个警报。当预置并发的利用率持续超过 70% 时，第一个警报会触发。发生这种情况时，Application Auto Scaling 会分配更多的预配置并发以降低利用率。当利用率持续低于 63%（70% 目标的 90%）时，第二个警报会触发。发生这种情况时，Application Auto Scaling 会减少别名的预配置并发。 **注意** 如果您的函数处于活跃状态并且正在接收请求，则 Lambda 会发出 `ProvisionedConcurrencyUtilization` 指标。在不活动期间，不会发出任何指标，并且您的自动扩缩警报将进入 `INSUFFICIENT_DATA` 状态。因此，Application Auto Scaling 将无法调整函数的预置并发。这可能会导致意外计费。 在以下示例中，函数会根据利用率在最小和最大预置并发量之间进行扩缩。 ![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/features-scaling-provisioned-auto.png) **图例** + ![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/features-scaling-provisioned.instances.png) 函数实例 + ![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/features-scaling-provisioned.open.png) 打开请求 + ![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) 预配置并发 + ![\[\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/features-scaling-provisioned.standard.png) 标准并发 打开的请求数量增加时，Application Auto Scaling 会大幅度增加预置并发，直到达到配置的最大值。达到最大值后，如果账户尚未达到账户并发数限制，则函数可能会在标准的非预留并发上继续扩展。利用率下降并保持较低时，Application Auto Scaling 会以较短周期逐步减少预置并发。 默认情况下，Application Auto Scaling 的两个警报都使用平均统计数据。具有快速突发流量的函数可能不会触发这些警报。例如，假设 Lambda 函数执行速度很快（如 20-100 毫秒），并且您的流量出现快速突发。在这种情况下，请求数超过了在突发期间分配的预置并发数。但是，突发负载需要维持至少 3 分钟，Application Auto Scaling 才能预置更多环境。此外，两个 CloudWatch 警报都需要获得 3 个达到目标平均水平的数据点，然后才能激活自动扩缩策略。**如果函数遭遇快速的流量爆发，使用 **Maximum** 统计数据而非 Average** 统计数据可以更有效地扩展预置并发数，从而最大限度地减少冷启动。 有关目标跟踪扩展策略的更多信息，请参阅[适用于 Application Auto Scaling 的目标跟踪扩展策略](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。