# 了解 Lambda 函数扩展
函数扩展

**并发**是您的 Amazon Lambda 函数同时处理的正在进行的请求数。对于每个并发请求，Lambda 会预置单独的执行环境实例。当您的函数收到更多请求时，Lambda 会自动处理执行环境数量的扩展，直到您达到账户的并发限制。默认情况下，Lambda 为您的账户提供的一个 Amazon Web Services 区域 中所有函数总并发上限为 1000 个并发执行。为了支持您的特定账户需求，您可以[申请增加限额](https://www.amazonaws.cn/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/)，并配置函数级并发控制，这样您的关键函数就不会节流。

本主题介绍了 Lambda 中的并发概念和函数横向缩减。在本主题结束时，您将能够了解如何计算并发、如何可视化两个主要的并发控制选项（预留类和预置类）、估计适当的并发控制设置，以及查看用于进一步优化的指标。

**Topics**
+ [

## 了解和可视化并发
](#understanding-concurrency)
+ [

## 计算函数的并发
](#calculating-concurrency)
+ [

## 了解预留并发和预置并发
](#reserved-and-provisioned)
+ [

## 了解并发和每秒请求数
](#concurrency-vs-requests-per-second)
+ [

## 并发限额
](#concurrency-quotas)
+ [

# 为函数配置预留并发
](configuration-concurrency.md)
+ [

# 为函数配置预置并发
](provisioned-concurrency.md)
+ [

# Lambda 扩展行为
](scaling-behavior.md)
+ [

# 监控并发
](monitoring-concurrency.md)

## 了解和可视化并发


Lambda 调用一个安全和隔离的[执行环境](lambda-runtime-environment.md)中的函数。要处理请求，Lambda 必须先初始化执行环境（[Init 阶段](lambda-runtime-environment.md#runtimes-lifecycle-ib)），然后再使用它来调用您的函数（[Invoke 阶段](lambda-runtime-environment.md#runtimes-lifecycle-invoke)）：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-1-environment.png)


**注意**  
实际的 Init 和 Invoke 持续时间可能因多种因素而异，例如您选择的运行时和 Lambda 函数代码。前面的图的目的并不是表示 Init 和 Invoke 阶段持续时间的确切比例。

上图使用矩形表示单个执行环境。当函数收到其第一个请求（由带标签 `1` 的黄色圆圈表示）时，Lambda 会创建一个新的执行环境并在初始化阶段在主处理程序之外运行代码。然后，Lambda 在 Invoke 阶段运行函数的主处理程序代码。在整个过程中，此执行环境繁忙，无法处理其他请求。

当 Lambda 处理完第一个请求后，此执行环境就可以处理针对同一函数的其他请求。对于后续请求，Lambda 无需重新初始化环境。

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-2-two-requests.png)


在上图中，Lambda 重复使用执行环境来处理第二个请求（由带标签 `2` 的黄色圆圈表示）。

到目前为止，我们只关注您的执行环境的单个实例（即并发为 1）。实际上，Lambda 可能需要并行预置多个执行环境实例来处理所有传入请求。当您的函数收到新请求时，可能会发生以下两种情况之一：
+ 如果预初始化的执行环境实例可用，Lambda 会使用它来处理请求。
+ 否则，Lambda 会创建一个新的执行环境实例来处理请求。

例如，让我们来看看当您的函数收到 10 个请求时会发生什么：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-3-ten-requests.png)


在上图中，每个水平平面代表一个执行环境实例（标记为从 `A` 到 `F`）。以下是 Lambda 处理每个请求的方式：


| 请求 | Lambda 行为 | Reasoning | 
| --- | --- | --- | 
|  1  |  预置新环境 **A**  |  这是第一个请求；没有可用的执行环境实例。  | 
|  2  |  预置新环境 **B**  |  现有执行环境实例 **A** 繁忙。  | 
|  3  |  预置新环境 **C**  |  现有执行环境实例 **A** 和 **B** 都繁忙。  | 
|  4  |  预置新环境 **D**  |  现有执行环境实例 **A**、**B** 和 **C** 都繁忙。  | 
|  5  |  预置新环境 **E**  |  现有执行环境实例 **A**、**B**、**C** 和 **D** 都繁忙。  | 
|  6  |  重用环境 **A**  |  执行环境实例 **A** 已处理完请求 **1**，现已可用。  | 
|  7  |  重用环境 **B**  |  执行环境实例 **B** 已处理完请求 **2**，现已可用。  | 
|  8  |  重用环境 **C**  |  执行环境实例 **C** 已处理完请求 **3**，现已可用。  | 
|  9  |  预置新环境 **F**  |  现有执行环境实例 **A**、**B**、**C**、**D** 和 **E** 都繁忙。  | 
|  10  |  重用环境 **D**  |  执行环境实例 **D** 已处理完请求 **4**，现已可用。  | 

随着您的函数收到更多的并发请求，Lambda 会纵向扩展响应中的执行环境实例的数量。以下动画跟踪一段时间内的并发请求数：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-4-animation.gif)


通过将之前的动画冻结在六个不同的时间点，我们得到下图：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-5-animation-summary.png)


在上图中，我们可以在任何时间点绘制一条垂直线，并计算与该直线相交的环境数量。这为我们提供了该时间点的并发请求数。例如，时间 `t1` 处有三个处于活动状态的环境在处理三个并发请求。此模拟中的最大并发请求数发生在时间 `t4`，此时有六个处于活动状态的环境处理六个并发请求。

总而言之，函数并发是它同时处理并发请求的数目。为了应对函数并发的增加，Lambda 预置了更多的执行环境实例以满足请求需求。

## 计算函数的并发


通常，系统的并发是指同时处理多个任务的能力。在 Lambda 中，并发是您的函数同时处理的正在进行的请求数。一种衡量 Lambda 函数并发的快速而实用的方法是使用以下公式：

```
Concurrency = (average requests per second) * (average request duration in seconds)
```

**并发不同于每秒的请求数。**例如，假设您的函数平均每秒接收 100 个请求。如果平均请求持续时间为一秒，那么并发确实也是 100：

```
Concurrency = (100 requests/second) * (1 second/request) = 100
```

但是，如果平均请求持续时间为 500 毫秒，则并发为 50：

```
Concurrency = (100 requests/second) * (0.5 second/request) = 50
```

实际上，并发为 50 意味着什么？ 如果平均请求持续时间为 500 毫秒，则可以将函数的实例视为每秒能够处理两个请求。然后，您的函数需要 50 个实例才能处理每秒 100 个请求的负载。并发为 50 意味着 Lambda 必须预置 50 个执行环境实例才能在没有任何节流的情况下高效处理此工作负载。以下是用方程式表示这种情况的方法：

```
Concurrency = (100 requests/second) / (2 requests/second) = 50
```

如果您的函数收到的请求数是原来的两倍（每秒 200 个请求），但只需要一半的时间来处理每个请求（250 毫秒），则并发仍为 50：

```
Concurrency = (200 requests/second) * (0.25 second/request) = 50
```

### 测试您对并发的理解


假设您有一个平均运行时间为 200 毫秒的函数。在峰值负载期间，可每秒观察 5000 个请求。在峰值负载期间，您的函数的并发是多少？ 

#### 回答


函数的平均持续时间为 200 毫秒或 0.2 秒。使用并发公式，您可以插入数字以获取 1,000 的并发：

```
Concurrency = (5,000 requests/second) * (0.2 seconds/request) = 1,000
```

或者，函数平均持续时间为 200 毫秒意味着您的函数每秒可处理 5 个请求。要处理每秒 5000 个请求的工作负载，您需要 1000 个执行环境实例。因此，并发为 1000：

```
Concurrency = (5,000 requests/second) / (5 requests/second) = 1,000
```

## 了解预留并发和预置并发


默认情况下，您的账户有某个区域内的所有函数的并发上限，该上限为 1000 个并行执行。您的函数按需共享这个拥有 1000 个并发的并发池。如果您用尽了可用的并发，您的函数将节流（即开始丢弃请求）。

您的某些函数可能比其他函数更重要。因此，您可能需要配置并发设置，以确保关键函数获得所需的并发。有两种并发控制：预留并发和预置并发。
+ 使用**预留并发**设置最大和最小并发实例数，以为某个函数预留部分账户并发数。如果您不想让其他函数占用所有可用的非预留并发，这非常有用。当一个函数有预留并发时，任何其他函数都不可以使用该并发。
+ 使用**预置并发**为一个函数预先初始化多个环境实例。这对于减少冷启动延迟很有用。

### 预留并发


若想保证您的函数在任何时候都有一定数量的并发可用，请使用预留并发。

预留并发设置您想要分配给函数的最大和最小并发实例数。当将预留并发提供给函数时，任何其他函数都不可以使用该并发。换言之，设置预留并发会影响可用于其他函数的并发池。没有预留并发的函数共享剩余的非预留并发池。

配置预留并发将计入您的账户总并发上限。为函数配置预留并发不收取任何费用。

为了更好地理解预留并发，请细看下图：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-6-reserved-concurrency.png)


在此图中，此区域中的所有函数的账户并发限制为默认限制 1000。假设您有两个关键函数 `function-blue` 和 `function-orange`，它们通常会预估获得很高的调用量。您决定将 400 个单位的预留并发分配给 `function-blue`，将 400 个单位的预留并发分配给 `function-orange`。在此示例中，您账户中的所有其他函数必须共享剩余的 200 个单位的非预留并发。

该图有五个兴趣点：
+ 在 `t1`，`function-orange` 和 `function-blue` 都开始接收请求。每个函数开始用完其预留并发单位的分配部分。
+ 在 `t2`，`function-orange` 和 `function-blue` 可稳步接收更多请求。同时，您部署了某些其他 Lambda 函数，这些函数开始接收请求。您不将预留并发分配给这些其他函数。它们开始使用剩余的 200 个单位的非预留并发。
+ 在 `t3`，`function-orange` 达到最大并发 400。尽管您的账户中的其他地方有未使用的并发，但 `function-orange` 无法访问它。红线表示 `function-orange` 处于节流状态，Lambda 可能会丢弃请求。
+ 在 `t4`，`function-orange` 开始接收更少的请求并且不再节流。但是，您的其他函数会遇到流量峰值并开始节流。尽管您的账户中的其他地方有未使用的并发，但其他函数无法访问它。红线表示您的其他函数处于节流状态。
+ 在 `t5`，其他函数开始接收更少的请求并且不再节流。

在此示例中，请注意，预留并发具有以下效果：
+ **您的函数可以独立于账户中的其他函数进行扩缩。**在没有预留并发的同一区域中，您所有账户的函数共享非预留并发池。如果没有预留并发，其他函数可能会耗尽所有您的可用的并发。从而导致关键函数无法根据需要进行纵向扩展。
+ **您的函数不能无节制地扩缩。**预留并发限制函数的最大和最小并发数。这意味着您的函数不能使用为其他函数预留的并发，也不能使用非预留池中的并发。此外，预留并发既充当下限，也充当上限，它专门为您的函数预留指定的容量，同时也防止其超出该限制扩展。您可以预留并发以防止您的函数使用您账户中的所有可用并发，或者防止下游资源过载。
+ **您可能无法使用账户的所有可用并发。**预留并发计入您的账户并发上限，但这也意味着其他函数无法使用这一大部分预留并发。如果您的函数没有用完您为它预留的所有并发，那么您实际上是在浪费这个并发。除非您账户中的其他函数可以从浪费的并发中受益，否则这不是问题。

要了解如何管理函数的预留并发设置，请参阅 [为函数配置预留并发](configuration-concurrency.md)。

### 预配置并发


您可以使用预留并发来定义为 Lambda 函数预留的最大执行环境数。但是，这些环境都不会进行预先初始化。因此，您的函数调用可能需要更长的时间，因为 Lambda 必须先初始化新环境，然后才能使用它来调用您的函数。当 Lambda 必须初始化新环境才能执行调用时，这称为[冷启动](lambda-runtime-environment.md#cold-start-latency)。为了减少冷启动，您可以使用预置并发。

预置并发是您要分配给函数的预初始化执行环境的数量。如果您在函数上设置预置并发，Lambda 会初始化该执行环境数量，以便它们准备好立即响应函数请求。

**注意**  
使用预置并发会让您的账户产生费用。如果您使用的是 Java 11 或 Java 17 运行时系统，则也可以使用 Lambda SnapStart 来缓解冷启动问题，而无需支付额外费用。SnapStart 使用执行环境的缓存快照来显著提高启动性能。您不能对同一个函数版本同时使用 SnapStart 和预置并发。有关 SnapStart 的功能、限制和支持的区域的更多信息，请参阅 [使用 Lambda SnapStart 提高启动性能](snapstart.md)。

当使用预置并发时，Lambda 仍会在后台回收执行环境。例如，这可能发生在[调用失败之后](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors)。但是，在任何给定时间，Lambda 始终确保预初始化环境的数量等于您的函数预置并发设置的值。重要的是，即使您使用预置并发，如果 Lambda 必须重置执行环境，您仍然会遇到冷启动延迟。

相反，当使用预留并发时，Lambda 可能会在一段时间不活动后完全终止环境。当您使用预留并发而不是预置并发来配置函数时，下图通过比较单个执行环境的生命周期来说明这一点。

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-7-reserved-vs-provisioned.png)


该图有四个兴趣点：


| 时间 | 预留并发 | 预配置并发 | 
| --- | --- | --- | 
|  t1  |  什么都未发生。  |  Lambda 预初始化一个执行环境实例。  | 
|  t2  |  请求 1 传入。Lambda 必须初始化一个新的执行环境实例。  |  请求 1 传入。Lambda 使用预初始化的环境实例。  | 
|  t3  |  在经过一段时间的不活动状态后，Lambda 会终止处于活动状态的环境实例。  |  什么都未发生。  | 
|  t4  |  请求 2 传入。Lambda 必须初始化一个新的执行环境实例。  |  请求 2 传入。Lambda 使用预初始化的环境实例。  | 

为了更好地了解预置并发，请细看下图：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-8-provisioned-concurrency.png)


在此图中，您的账户并发限制为 1,000。您决定将 400 个单位的预置并发量分配给 `function-orange`。您账户中的所有函数，*包括* `function-orange`，都可以使用剩余的 600 个单位的非预留并发。

该图有五个兴趣点：
+ 在 `t1`，`function-orange` 开始接收请求。由于 Lambda 已经预先初始化 400 个执行环境实例，`function-orange` 可以立即调用。
+ 在 `t2`，`function-orange` 达到 400 个并发请求。因此，`function-orange` 已用尽预置并发。但是，由于仍有非预留并发可用，Lambda 可以使用它来处理对 `function-orange` 的额外请求（没有节流）。Lambda 必须创建新实例来处理这些请求，并且您的函数可能会遇到冷启动延迟。
+ 在 `t3`，`function-orange` 在短暂的流量峰值后返回 400 个并发请求。Lambda 能够再次在没有冷启动延迟的情况下处理所有请求。
+ 在 `t4`，您账户中的函数会遇到流量突增的情况。这种突增可能产生于 `function-orange` 或您账户中的任何其他函数。Lambda 使用非预留并发来处理这些请求。
+ 在 `t5`，您的账户中的函数达到 1,000 的最大并发上限，并且会节流。

前面的示例仅考虑了预置并发。实际上，您可以设置函数的预置并发和预留并发。如果您有一个函数可以处理工作日的恒定调用负载，但是在周末经常出现流量峰值，那么您可以这样做。在这种情况下，您可以使用预置并发来设置基准环境数量以在工作日处理请求，并使用预留并发来处理周末的流量峰值。请细看以下图：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-9-reserved-and-provisioned.png)


在此图中，假设您为 `function-orange` 配置了 200 个单位的预置并发和 400 个单位的预留并发。由于您配置了预留并发，因此 `function-orange` 无法使用 600 个单位的非预留并发中的任何一个。

该图有五个兴趣点：
+ 在 `t1`，`function-orange` 开始接收请求。由于 Lambda 已经预先初始化 200 个执行环境实例，`function-orange` 可以立即调用。
+ 在 `t2`，`function-orange` 已用尽其所有的预置并发。`function-orange` 可以继续使用预留并发来处理请求，但这些请求可能会遇到冷启动延迟。
+ 在 `t3`，`function-orange` 达到 400 个并发请求。因此，`function-orange` 已用尽其所有预留并发。由于 `function-orange` 无法使用非预留并发，因此请求开始节流。
+ 在 `t4`，`function-orange` 开始接收更少的请求并且不再节流。
+ 在 `t5`，`function-orange` 降至 200 个并发请求，因此所有请求都能够再次使用预置并发（即没有冷启动延迟）。

预留并发和预置并发均计入您的账户并发限制和[区域限额](gettingstarted-limits.md)。换言之，分配预留和预置并发会影响可用于其他函数的并发池。配置预置并发会让您的 Amazon Web Services 账户 产生费用。

**注意**  
如果函数版本与别名功能上的预配置并发数加起来达到函数的预留并发，则所有调用都在预配置并发上运行。此配置还具有限制函数 (`$LATEST`) 未发布版本的效果，从而阻止其执行。为函数分配的预配置并发数不能超过预留并发数。

要管理函数的预置并发设置，请参阅 [为函数配置预置并发](provisioned-concurrency.md)。要根据计划或应用程序利用率自动执行预置并发扩展，请参阅 [使用 Application Auto Scaling 自动执行预置并发管理](provisioned-concurrency.md#managing-provisioned-concurency)。

### Lambda 如何分配预置并发


配置后，预置并发并不会立即生效。Lambda 会在一两分钟的准备时间后开始分配预配置并发。无论所处的 Amazon Web Services 区域 如何，Lambda 每分钟最多可为每个函数预置 6000 个执行环境。这与函数的[并发扩展速率](scaling-behavior.md#scaling-rate)完全相同。

当您提交分配预置并发的请求时，在 Lambda 完全完成分配之前，您无法访问任何这些环境。例如，若请求 5000 个预置并发，则需等待 Lambda 完全完成对 5000 个执行环境的分配后，请求才能使用预置的并发。

### 对比预留并发和预置并发。


下表总结并对比了预留并发和预置并发。


| Topic | 预留并发 | 预配置并发 | 
| --- | --- | --- | 
|  定义  |  您的函数的最大执行环境实例数。  |  设置您的函数的预置执行环境实例数。  | 
|  预置行为  |  Lambda 按需预置新实例。  |  Lambda 预置实例（即在您的函数开始接收请求之前）。  | 
|  冷启动行为  |  由于 Lambda 必须按需创建新实例，因此可能出现冷启动延迟。  |  由于 Lambda 不必按需创建实例，因此不可能发生冷启动延迟。  | 
|  节流行为  |  当达到预留并发限制时，函数会被节流。  |  如果未设置预留并发：当达到预置并发限制时，函数将使用非预留并发。 如果设置了预留并发：当达到预留并发限制时，函数会被节流。  | 
|  如果未设置，则为默认行为  |  函数使用您的账户中可用的非预留并发。  |  Lambda 不预置任何实例。相反，如果没有设置预留并发：函数使用您的账户中可用的非预留并发。 如果设置了预留并发：函数使用预留并发。  | 
|  定价  |  无额外费用。  |  会产生额外费用。  | 

## 了解并发和每秒请求数


如上一节中所述，并发不同于每秒的请求数。在处理平均请求持续时间小于 100 毫秒的函数时，这是一项特别重要的区别。

对于账户中的所有函数，Lambda 强制执行每秒请求数限制，此限制相当于您的账户并发数的 10 倍。例如，由于默认账户并发限制为 1000，因此您账户中的函数每秒最多可以处理 10000 个请求。

例如，考虑一个平均请求持续时间为 50 毫秒的函数。在每秒 20000 个请求时，以下是此函数的并发：

```
Concurrency = (20,000 requests/second) * (0.05 second/request) = 1,000
```

基于此结果，您可能会认为 1000 的账户并发限制足以处理此负载。但是，由于每秒 10000 个请求的限制，您的函数每秒只能处理 20000 个请求总数中的 10000 个请求。此函数会受到节流。

教训是，在为函数配置并发设置时，必须同时考虑并发和每秒请求数。在这种情况下，您需要请求将账户并发限制增加到 2000，因为这将使每秒请求总数限制增加到 20000。

**注意**  
基于此每秒请求数限制，说每个 Lambda 执行环境每秒最多只能处理 10 个请求是不正确的。在计算配额时，Lambda 不会观察任何单个执行环境中的负载，而是仅考虑总体并发数和每秒总请求数。

### 测试您对并发的理解（低于 100 毫秒的函数）


假设您有一个平均运行时间为 20 毫秒的函数。在峰值负载期间，可每秒观察 30000 个请求。在峰值负载期间，您的函数的并发是多少？

#### 回答


函数的平均持续时间为 20 毫秒或 0.02 秒。使用并发公式，您可以插入数字以获取 600 的并发数：

```
Concurrency = (30,000 requests/second) * (0.02 seconds/request) = 600
```

默认情况下，账户并发限制 1000 似乎足以处理此负载。但是，每秒 10000 个请求的限制不足以处理每秒传入 30000 个请求。要完全满足 30000 个请求，您需要请求将账户并发限制增加到 3000 或以上。

每秒请求数限制适用于 Lambda 中涉及并发的所有配额。换句话说，它适用于同步按需函数、使用预置并发的函数和[并发扩展行为](scaling-behavior.md)。例如，在以下几种情况下，您必须仔细考虑并发数和每秒请求数限制：
+ 使用按需并发的函数可能会每 10 秒突增 500 个并发，或者每 10 秒突增 5000 个请求（以先发生者为准）。
+ 假设您有一个函数，其预置并发分配为 10。此函数在每秒 10 个并发或 100 个请求后溢出到按需并发（以先发生者为准）。

## 并发限额


对于可跨区域中所有函数使用的并发的总量，Lambda 可设置限额。这些限额分为两个级别：
+ **在账户级别**，默认情况下，您的函数最多可以有 1000 个单位的并发。要提高此限制，请参阅 *Service Quotas User Guide*（《服务限额用户指南》）中的 [Requesting a quota increase](https://docs.amazonaws.cn/servicequotas/latest/userguide/request-quota-increase.html)（请求增加限额）。
+ **在函数级别**，默认情况下，您可以为所有函数保留最多 900 个单位的并发。无论您的账户总并发限制如何设置，Lambda 始终为未明确保留并发的函数预留 100 个并发单位。例如，如果您将账户并发限制提高到 2000，则可以在函数级别预留最多 1900 个单位的并发。
+ 在账户级别和函数级别，Lambda 还强制执行每秒请求数限制，此限制相当于相应并发配额的 10 倍。例如，这适用于账户级并发、使用按需并发的函数、使用预置并发的函数和[并发扩展行为](scaling-behavior.md)。有关更多信息，请参阅 [了解并发和每秒请求数](#concurrency-vs-requests-per-second)。

要检查您的当前账户级别并发限额，请使用 Amazon Command Line Interface（Amazon CLI）运行以下命令：

```
aws lambda get-account-settings
```

您应该会看到类似如下输出：

```
{
    "AccountLimit": {
        "TotalCodeSize": 80530636800,
        "CodeSizeUnzipped": 262144000,
        "CodeSizeZipped": 52428800,
        "ConcurrentExecutions": 1000,
        "UnreservedConcurrentExecutions": 900
    },
    "AccountUsage": {
        "TotalCodeSize": 410759889,
        "FunctionCount": 8
    }
}
```

`ConcurrentExecutions` 是您的账户级别的总并发限额。`UnreservedConcurrentExecutions` 是您仍然可以分配给函数的预留并发。

当您的函数收到更多请求时，Lambda 会自动纵向扩展执行环境的数量来处理这些请求，直到账户达到其并发限额。但是，为了防止因突然的流量爆发而出现过度扩展，Lambda 限制了函数的扩展速度。此**并发扩展速率**是您账户中的函数在应对增加的请求时可以扩展的最大速率。（也就是 Lambda 创建新执行环境的速度。） 并发扩展速率不同于账户级别的并发限制，后者是函数可用的并发总量。

**在每个 Amazon Web Services 区域 中，对于每个函数，您的并发扩展速率为每 10 秒 1000 个执行环境实例（或每 10 秒 10000 个请求）。**换句话说，每 10 秒 Lambda 最多可以为每个函数分配 1000 个额外的执行环境实例，或者每秒满足 10000 个额外的请求。

通常，您无需关注此限制。Lambda 的扩展速率足以满足大多数用例的需求。

重要的是，并发扩展速率是函数级别的限制。这意味着您账户中的每个函数可以独立于其他函数进行扩展。

有关扩展行为的更多信息，请参阅 [Lambda 扩展行为](scaling-behavior.md)。

# 为函数配置预留并发
配置预留并发

在 Lambda 中，[并发](lambda-concurrency.md)指您的函数当前正在进行的请求数。有两种类型的并发控件可用：
+ 预留并发 – 这将设置分配给您的函数的最大和最小并发实例数。当一个函数有预留并发时，任何其他函数都不可以使用该并发。对于确保最关键的函数始终具有足够的并发性来处理传入请求，预留并发非常有用。此外，预留并发可用于限制并发，以防止下游资源（如数据库连接）不堪重负。预留并发既充当下限，也充当上限，它专门为您的函数预留指定的容量，同时也防止其超出该限制扩展。为函数配置预留并发不产生任何额外费用。
+ 预置并发 – 指分配给函数的预初始化执行环境的数量。这些执行环境已准备就绪，可以立即响应传入的函数请求。预置并发有助于减少函数的冷启动延迟，旨在使函数具有两位数毫秒的响应时间。通常，交互式工作负载从该功能中获益最大。这些是用户发起请求的应用程序（例如 Web 和移动应用程序），并且对延迟最敏感。异步工作负载（例如数据处理管线）经常对延迟不太敏感，因此通常不需要预置并发。配置预置并发会让您的 Amazon Web Services 账户 产生额外费用。

本主题详细介绍了如何管理和配置预留并发。有关这两种并发控制的概念概述，请参阅[预留并发和预置并发](https://docs.amazonaws.cn/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)。有关配置预置并发的信息，请参阅 [为函数配置预置并发](provisioned-concurrency.md)。

**注意**  
关联到 Amazon MQ 事件源映射的 Lambda 函数具有默认的最大并发数。对于 Apache Active MQ，最大并发实例数为 5。对于 Rabbit MQ，最大并发实例数为 1。为函数设置预留或预调配的并发不会更改这些限制。要在使用 Amazon MQ 时请求增加默认的最大并发数，请联系 Amazon Web Services 支持。

**Topics**
+ [

## 配置预留并发
](#configuring-concurrency-reserved)
+ [

## 准确估计函数所需的预留并发
](#estimating-reserved-concurrency)

## 配置预留并发


您可以使用 Lambda 控制台或 Lambda API 为函数配置预留并发设置。

**为函数预留并发（控制台）**

1. 打开 Lamba 控制台的[函数页面](https://console.amazonaws.cn/lambda/home#/functions)。

1. 选择要为其预留并发的函数。

1. 选择 **Configuration**（配置），然后选择 **Concurrency**（并发）。

1. 在**并发**下，选择**编辑**。

1. 选择**预留并发**。输入要为该函数预留的并发数量。

1. 选择**保存**。

您最多可以预留的单位数量为**非预留账户并发**值减去 100。剩余 100 个单位的并发可用于不会使用预留并发的函数。例如，如果您的账户的并发上限为 1000，则不能将所有 1000 个单位的并发预留给单个函数。

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-reserve-over-limit.png)


为一个函数预留并发会影响可用于其他函数的并发池。例如，如果您为 `function-a` 预留 100 个单位的并发，则即使 `function-a` 不使用所有 100 个单位的预留并发，您账户中的其他函数也必须共享剩余的 900 个单位的并发。

要有意限制函数，请将其预留并发设置为 0。这将停止函数处理任何事件，直到您删除限制。

要使用 Lambda API 配置预留并发，请使用以下 API 操作。
+ [PutFunctionConcurrency](https://docs.amazonaws.cn/lambda/latest/api/API_PutFunctionConcurrency.html)
+ [GetFunctionConcurrency](https://docs.amazonaws.cn/lambda/latest/api/API_GetFunctionConcurrency.html)
+ [DeleteFunctionConcurrency](https://docs.amazonaws.cn/lambda/latest/api/API_DeleteFunctionConcurrency.html)

例如，要使用 Amazon Command Line Interface（CLI）配置预留并发，请使用 `put-function-concurrency` 命令。以下命令为名为 `my-function` 的函数预留 100 个单位的并发：

```
aws lambda put-function-concurrency --function-name my-function \
    --reserved-concurrent-executions 100
```

您应该会看到类似如下输出：

```
{
    "ReservedConcurrentExecutions": 100
}
```

## 准确估计函数所需的预留并发


如果您的函数当前正在提供流量，则可以使用 [CloudWatch 指标](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)轻松查看其并发指标。具体而言，`ConcurrentExecutions` 指标显示了您账户中每个函数的并发调用数。

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)


前面的图表显示，在给定的任何时间，此函数平均处理 5 到 10 个并发请求，峰值通常为 20 个请求。假设您的账户中还有许多其他函数。**如果此函数对您的应用程序至关重要，并且您不想丢弃任何请求**，请使用大于或等于 20 的数字作为预留的并发设置。

请注意，您也可以使用以下公式[计算并发](https://docs.amazonaws.cn/lambda/latest/dg/lambda-concurrency.html#calculating-concurrency)：

```
Concurrency = (average requests per second) * (average request duration in seconds)
```

将每秒的平均请求数与平均请求持续时间（以秒为单位）相乘可以粗略估计您需要预留多少并发。您可以使用 `Invocation` 指标估算每秒的平均请求数，并使用 `Duration` 指标估计平均请求持续时间（以秒为单位）。有关更多信息，请参阅[将 CloudWatch 指标与 Lambda 结合使用](monitoring-metrics.md)。

您还应该熟悉上游和下游吞吐量限制。虽然 Lambda 函数可随负载无缝扩展，但上游和下游依赖项可能不具有相同的吞吐量。如果您需要限制函数可以扩展的幅度，可以为函数配置预留并发。

# 为函数配置预置并发
配置预配置并发

在 Lambda 中，[并发](lambda-concurrency.md)指您的函数当前正在进行的请求数。有两种类型的并发控件可用：
+ 预留并发 – 这将设置分配给您的函数的最大和最小并发实例数。当一个函数有预留并发时，任何其他函数都不可以使用该并发。对于确保最关键的函数始终具有足够的并发性来处理传入请求，预留并发非常有用。此外，预留并发可用于限制并发，以防止下游资源（如数据库连接）不堪重负。预留并发既充当下限，也充当上限，它专门为您的函数预留指定的容量，同时也防止其超出该限制扩展。为函数配置预留并发不产生任何额外费用。
+ 预置并发 – 指分配给函数的预初始化执行环境的数量。这些执行环境已准备就绪，可以立即响应传入的函数请求。预置并发有助于减少函数的冷启动延迟，旨在使函数具有两位数毫秒的响应时间。通常，交互式工作负载从该功能中获益最大。这些是用户发起请求的应用程序（例如 Web 和移动应用程序），并且对延迟最敏感。异步工作负载（例如数据处理管线）经常对延迟不太敏感，因此通常不需要预置并发。配置预置并发会让您的 Amazon Web Services 账户 产生额外费用。

本主题详细介绍了如何管理和配置预置并发。有关这两种并发控制的概念概述，请参阅[预留并发和预置并发](https://docs.amazonaws.cn/lambda/latest/dg/lambda-concurrency.html#reserved-and-provisioned)。有关配置预留并发的更多信息，请参阅[为函数配置预留并发](configuration-concurrency.md)。

**注意**  
关联到 Amazon MQ 事件源映射的 Lambda 函数具有默认的最大并发数。对于 Apache Active MQ，最大并发实例数为 5。对于 Rabbit MQ，最大并发实例数为 1。为函数设置预留或预调配的并发不会更改这些限制。要在使用 Amazon MQ 时请求增加默认的最大并发数，请联系 Amazon Web Services 支持。

**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.amazonaws.cn/lambda/home#/functions)。

1. 选择要为其分配预置并发的函数。

1. 选择 **Configuration**（配置），然后选择 **Concurrency**（并发）。

1. 在 **Provisioned concurrency configurations（预配置并发配置）**下，选择 **Add configuration（添加配置）**。

1. 选择限定符类型以及别名或版本。
**注意**  
您不能将预置并发与任何函数的 \$1LATEST 版本一起使用。  
如果函数具有事件源，请确保该事件源指向正确的函数别名或版本。否则，您的函数将不会使用预置并发环境。

1. 在**预置并发**下输入一个数字。

1. 选择**保存**。

您最多可以在账户中配置的单位数量为**非预留账户并发**减去 100。剩余 100 个单位的并发可用于不会使用预留并发的函数。例如，如果您的账户的并发限制为 1000，并且您没有为任何其他函数分配任何预留或预置并发，则可以为单个函数配置最多 900 个单位的预置并发。

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/provisioned-concurrency-over-limit.png)


为函数配置预置并发会影响可用于其他函数的并发池。例如，如果您为 `function-a` 配置 100 个单位的预置并发，则您账户中的其他函数必须共享剩余的 900 个单位的并发。即使 `function-a` 不使用所有 100 个单位的预置并发也是如此。

可以为同一函数同时分配预留并发和预置并发。在这种情况下，预置并发数不能超过预留并发数。

此限制也适用于函数版本。您可以分配给特定函数版本的最大预置并发数等于该函数的预留并发减去其他函数版本上配置的预置并发。

要使用 Lambda API 配置预置并发，请使用以下 API 操作：
+ [PutProvisionedConcurrencyConfig](https://docs.amazonaws.cn/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [GetProvisionedConcurrencyConfig](https://docs.amazonaws.cn/lambda/latest/api/API_GetProvisionedConcurrencyConfig.html)
+ [ListProvisionedConcurrencyConfigs](https://docs.amazonaws.cn/lambda/latest/api/API_ListProvisionedConcurrencyConfigs.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.amazonaws.cn/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)

例如，要使用 Amazon 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.amazonaws.cn/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)查看任何活动函数的并发指标。具体而言，`ConcurrentExecutions` 指标显示了您账户中函数的并发调用数。

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-concurrent-executions-metrics.png)


前面的图表显示，在给定的任何时间，此函数平均处理 5 到 10 个并发请求，峰值为 20 个请求。假设您的账户中还有许多其他函数。**如果此函数对您的应用程序至关重要，并且您的每次调用都需要低延迟响应**，请配置至少 20 个单位的预置并发。

请注意，您也可以使用以下公式[计算并发数](https://docs.amazonaws.cn/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.amazonaws.cn/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 也会对初始化进行计费。预配置并发连续运行，并且与初始化和调用成本分开计费。有关更多详细信息，请参阅 [Amazon Lambda 定价](https://www.amazonaws.cn/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.amazonaws.cn/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)，以及在 Amazon 计算博客上的[为经常出现的峰值使用情况计划 Amazon Lambda 预置并发](https://www.amazonaws.cn/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/)。

### 目标跟踪


借助目标跟踪，Application Auto Scaling 可根据您定义扩展策略的方式创建和管理一组 CloudWatch 警报。当这些警报激活时，Application Auto Scaling 会使用预置并发自动调整分配的环境数量。针对流量模式不可预测的应用程序，使用目标跟踪。

要使用目标跟踪扩展预置并发，请使用 `RegisterScalableTarget` 和 `PutScalingPolicy` Application Auto Scaling API 操作。例如，如果您使用的是 Amazon 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.amazonaws.cn/lambda/latest/dg/images/features-scaling-provisioned-auto.png)


**图例**
+ ![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/features-scaling-provisioned.instances.png) 函数实例
+ ![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/features-scaling-provisioned.open.png) 打开请求
+ ![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/features-scaling-provisioned.provisioned.png) 预配置并发
+ ![\[\]](http://docs.amazonaws.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.amazonaws.cn/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)。

# Lambda 扩展行为
扩展行为

当您的函数收到更多请求时，Lambda 会自动纵向扩展执行环境的数量来处理这些请求，直到账户达到其并发限额。但是，为了防止因突然的流量爆发而出现过度扩展，Lambda 限制了函数的扩展速度。此**并发扩展速率**是您账户中的函数在应对增加的请求时可以扩展的最大速率。（也就是 Lambda 创建新执行环境的速度。） 并发扩展速率不同于账户级别的并发限制，后者是函数可用的并发总量。

## 并发扩展速率


**在每个 Amazon Web Services 区域 中，对于每个函数，您的并发扩展速率为每 10 秒 1000 个执行环境实例（或每 10 秒 10000 个请求）。**换句话说，每 10 秒 Lambda 最多可以为每个函数分配 1000 个额外的执行环境实例，或者每秒满足 10000 个额外的请求。

通常，您无需关注此限制。Lambda 的扩展速率足以满足大多数用例的需求。

重要的是，并发扩展速率是函数级别的限制。这意味着您账户中的每个函数可以独立于其他函数进行扩展。

**注意**  
实际上，Lambda 会尽最大努力随着时间的推移持续重新填充您的并发扩展速率，而不是每隔 10 秒一次填充 1,000 个单位。

Lambda 不会累积并发扩展速率中未使用的部分。这意味着，无论在任何时候，扩展速率的最大值始终为 1,000 个并发单位。例如，如果您在 10 秒间隔内没有使用可用的 1,000 个并发单元中的任何一个，则在下一个 10 秒间隔内，不会累加 1,000 个额外的单位。在下一个 10 秒间隔内，您的并发扩展速率仍为 1,000。

只要您的函数继续收到越来越多的请求，Lambda 就会以您可用的最快速率进行扩展，直至达到账户的并发限制。您可以通过[配置预留并发](configuration-concurrency.md)来限制单个函数可以使用的并发数量。如果请求进入的速度超过函数可扩展的速度，或者如果函数处于最大并发，则其他请求会因节流错误而失败（状态代码为 429）。

# 监控并发
监控并发

Lambda 会发送 Amazon CloudWatch 指标，以帮助监控函数的并发。本主题解释了这些指标以及如何解读指标。

**Topics**
+ [

## 一般并发指标
](#general-concurrency-metrics)
+ [

## 预配置并发指标
](#provisioned-concurrency-metrics)
+ [

## 使用 `ClaimedAccountConcurrency` 指标
](#claimed-account-concurrency)

## 一般并发指标


使用以下指标监控 Lambda 函数并发。各指标的粒度为 1 分钟。
+ `ConcurrentExecutions` – 给定时间点处于活动状态的并发调用数。Lambda 会针对所有函数、别名和版本发送该指标。对于 Lambda 控制台中的任何函数，Lambda 会在**指标**下的**监控**选项卡中原生显示 `ConcurrentExecutions` 的图表。使用 **MAX** 查看该指标。
+ `UnreservedConcurrentExecutions` – 使用非预留并发的处于活动状态的并发调用数。Lambda 会向区域中所有函数发出该指标。使用 **MAX** 查看该指标。
+ `ClaimedAccountConcurrency` – 不可用于按需调用的并发数。`ClaimedAccountConcurrency` 等于 `UnreservedConcurrentExecutions` 加上分配的并发数（即总预留并发数加上总预置并发数）。如果 `ClaimedAccountConcurrency` 超出账户并发限制，则可以[申请更高的账户并发数限制](https://www.amazonaws.cn/premiumsupport/knowledge-center/lambda-concurrency-limit-increase/)。使用 **MAX** 查看该指标。有关更多信息，请参阅 [使用 `ClaimedAccountConcurrency` 指标](#claimed-account-concurrency)。

## 预配置并发指标


使用预置并发时，使用以下指标监控 Lambda 函数。各指标的粒度为 1 分钟。
+ `ProvisionedConcurrentExecutions` – 正在积极处理预置并发调用的执行环境实例的数目。Lambda 会根据配置的预置并发，为每个函数版本和别名发送该指标。使用 **MAX** 查看该指标。

`ProvisionedConcurrentExecutions` 与您分配的预置并发总数不同。例如，假设您为某个函数版本分配了 100 个单位的预置并发。在任何给定的一分钟内，如果这 100 个执行环境中最多有 50 个会同时处理调用，则 **MAX** (`ProvisionedConcurrentExecutions`) 的值为 50。
+ `ProvisionedConcurrencyInvocations` – Lambda 使用预置并发调用函数代码的次数。Lambda 会根据配置的预置并发，为每个函数版本和别名发送该指标。使用 **SUM** 查看该指标。

`ProvisionedConcurrencyInvocations` 与 `ProvisionedConcurrentExecutions` 的不同之处在于，`ProvisionedConcurrencyInvocations` 会计算调用总次数，而 `ProvisionedConcurrentExecutions` 会计算处于活动状态的环境的数量。要理解这种区别，请考虑以下情形：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/concurrency-metrics-pc-executions-vs-invocations.png)


在本例中，假设您每分钟收到 1 次调用，并且每次调用需要 2 分钟才能完成。每个橙色水平条形代表一个请求。假设您为该函数分配 10 个单位的预置并发，此时每个请求都会在预置并发上运行。

在 0 到 1 分钟之间，`Request 1` 会传入。**在第 1 分钟**，**MAX** (`ProvisionedConcurrentExecutions`) 的值为 1，因为在过去一分钟内，至多 1 个执行环境处于活动状态。**SUM** (`ProvisionedConcurrencyInvocations`) 的值也为 1，因为在过去一分钟内传入了 1 个新请求。

在第 1 分钟到第 2 分钟之间，`Request 2` 会传入，并且 `Request 1` 会继续运行。**在第 2 分钟**，**MAX** (`ProvisionedConcurrentExecutions`) 的值为 2，因为在过去一分钟内至多 2 个执行环境处于活动状态。但是，**SUM** (`ProvisionedConcurrencyInvocations`) 的值为 1，因为在过去一分钟内只传入了 1 个新请求。这种指标行为一直持续到示例结束。
+ `ProvisionedConcurrencySpilloverInvocations` – 当所有预置并发均处于使用状态时，Lambda 根据标准（预留或非预留）并发调用函数的次数。Lambda 会根据配置的预置并发，为每个函数版本和别名发送该指标。使用 **SUM** 查看该指标。`ProvisionedConcurrencyInvocations` \$1 `ProvisionedConcurrencySpilloverInvocations` 的值应等于函数调用的总次数（即 `Invocations` 指标）。

  `ProvisionedConcurrencyUtilization` – 正在使用的预置并发的百分比（即 `ProvisionedConcurrentExecutions` 除以分配的预置并发总量的值）。Lambda 会根据配置的预置并发，为每个函数版本和别名发送该指标。使用 **MAX** 查看该指标。

例如，假设您为某个函数版本预置了 100 个单位的预置并发。在任何给定的一分钟内，如果这 100 个执行环境中最多有 60 个同时处理调用，则 **MAX** (`ProvisionedConcurrentExecutions`) 的值为 60，**MAX** (`ProvisionedConcurrencyUtilization`) 的值为 0.6。

`ProvisionedConcurrencySpilloverInvocations` 的值较高可能表示您需要为函数分配限额外的预置并发。或者，您可以[配置 Application Auto Scaling 以根据预定义的阈值处理预置并发的自动扩缩](https://docs.amazonaws.cn/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency)。

相反，`ProvisionedConcurrencyUtilization` 的值持续较低可能表明您为函数分配了过多的预置并发。

## 使用 `ClaimedAccountConcurrency` 指标


Lambda 使用 `ClaimedAccountConcurrency` 指标来确定您的账户可用于按需调用的并发数。Lambda 将使用以下公式计算 `ClaimedAccountConcurrency`：

```
ClaimedAccountConcurrency = UnreservedConcurrentExecutions + (allocated concurrency)
```

`UnreservedConcurrentExecutions` 指使用非预留并发的处于活动状态的并发调用数。分配的并发是以下两部分的总和（将 `RC` 替换为“预留并发”，`PC` 替换为“预置并发”）：
+ 区域中所有函数的总 `RC`。
+ 一个区域中所有使用 `PC` 的函数的总 `PC`，不包括使用 `RC` 的函数。

**注意**  
为一个函数分配的 `PC` 不能超过 `RC`。因此，函数的 `RC` 总是大于或等于其 `PC`。为了计算同时使用 `PC` 和 `RC` 的此类函数对分配并发的贡献，Lambda 只考虑两者中最大的 `RC`。

Lambda 使用 `ClaimedAccountConcurrency` 指标，而不是 `ConcurrentExecutions` 指标，来确定可用于按需调用的并发数。虽然 `ConcurrentExecutions` 指标非常适用于跟踪活动并发调用数，但其并不总是能反映真实的并发可用性。这是因为 Lambda 还会考虑预留并发和预置并发来确定可用性。

要说明 `ClaimedAccountConcurrency`，假设在一个场景中，您在基本上未使用的函数中配置了大量预留并发和预置并发。在以下示例中，假设您的账户并发数限制为 1000，并且账户中有两个主要函数：`function-orange` 和 `function-blue`。您为 `function-orange` 分配了 600 个单位的预留并发。您为 `function-blue` 分配了 200 个单位的预置并发。假设随着时间的推移，您会部署其他函数并观测到以下流量模式：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/claimed-account-concurrency.png)


在上图中，黑线表示一段时间内的实际并发使用情况，红线表示一段时间内的 `ClaimedAccountConcurrency` 值。尽管各函数的实际并发利用率较低，但在整个场景中，`ClaimedAccountConcurrency` 至少为 800。这是因为您总共为 `function-orange` 和 `function-blue` 分配了 800 个单位的并发。从 Lambda 的角度来看，您已经“申请”了此并发以供使用，因此其他函数实际上只剩下 200 个单位的并发。

该场景中，`ClaimedAccountConcurrency` 公式中分配的并发数为 800。然后我们可以推导出图中不同点处的 `ClaimedAccountConcurrency` 值：
+ `t1` 点处，`ClaimedAccountConcurrency` 等于 800 (800 \$1 0 `UnreservedConcurrentExecutions`)。
+ `t2` 点处，`ClaimedAccountConcurrency` 等于 900 (800 \$1 100 `UnreservedConcurrentExecutions`)。
+ `t3` 点处，`ClaimedAccountConcurrency` 又等于 900 (800 \$1 100 `UnreservedConcurrentExecutions`)。

### 在 CloudWatch 中设置 `ClaimedAccountConcurrency` 指标


Lambda 在 CloudWatch 中发出 `ClaimedAccountConcurrency` 指标。使用此指标以及 `SERVICE_QUOTA(ConcurrentExecutions)` 值可以获得账户中并发利用率的百分比，如以下公式所示：

```
Utilization = (ClaimedAccountConcurrency/SERVICE_QUOTA(ConcurrentExecutions)) * 100%
```

以下屏幕截图说明了如何在 CloudWatch 中绘制此公式的图表。绿 `claim_utilization` 线表示此账户中的并发利用率，约为 40%：

![\[\]](http://docs.amazonaws.cn/lambda/latest/dg/images/claimed-account-concurrency-cloudwatch-graph.png)


上一个屏幕截图还包括 CloudWatch 警报，当并发利用率超过 70% 时，该警报会进入 `ALARM` 状态。您可以使用 `ClaimedAccountConcurrency` 指标以及类似警报来主动确定何时可能需要请求更高的账户并发数限制。