tencent cloud

并发是云函数在某个时刻同时处理的请求数。在业务其他服务可以支撑的情况下，您可以通过简单的配置实现云函数从几个并发到数以万计并发的拓展。

应用场景

高 QPS 短运行时长

使用云函数进行简单的数据、文件处理，例如对象存储触发云函数进行信息上报、对文件处理等。此类场景下单次请求运行时间较短。

重计算长时间运行

使用云函数进行音视频转码、数据处理、AI 推理等场景，由于模型加载等操作导致函数初始化时间长、函数运行的时间长。包括 Java 运行环境的初始化时间较长。

异步消息处理

使用云函数做异步消息处理的场景较多，例如全景录制场景，腾讯云自研的全景录制，主打所见即所得的录制理念；TDMQ 函数触发场景，可最大程度的衔接消息队列两端的数据上下游，帮助用户实现 Serverless 体系下的异步事件解耦和削峰填谷的能力等。

产品优势

通过综合使用最大独占配额、预置并发等能力，您可以灵活调配多个函数间的资源用量情况，并按需预热函数。

共享配额

在未进行各项配置的情况下，各函数默认共享使用账号额度。如果有某个函数产生了突增业务调用，可以充分利用空闲未使用的额度，来保证突增不会引起函数的调用并发超限。

并发保障

如果有某个函数的业务功能比较敏感或关键，需要尽力保障请求的成功率，此时可以使用最大独占配额。最大独占配额可以给到函数独享额度，确保并发的可靠性，不会由于多函数的争抢导致的调用并发超限。

预置并发

在函数对冷启动敏感、或代码初始化流程耗时较长、加载库较多的情况下，可以通过设置具体函数版本的预置并发，预先启动函数实例来保障运行。

并发扩容原理

并发实例复用与回收与并发扩容原理详情见 并发概述。

示例

例如，广州地域的账号默认并发额度可以支撑128MB函数的1000个并发实例。有大量请求到来时，第一分钟可以从0个并发实例启动到500个并发实例。如果还有请求需要处理，第二分钟可以从500个并发实例启动到1000个并发实例。

下图模拟了业务流量峰值时函数并发处理的具体场景。随着业务请求量不断增加，没有可用并发实例处理新的请求时，函数将启动新的并发实例进行扩容。当达到弹性并发的扩容速度限制时，函数扩容速度逐渐变慢，新的请求将会受到限制尝试重试。接着函数会继续扩容，最终达到函数区域对账户的并发限制。最终在满足业务需求后，请求量逐步减少，函数未使用的并发实例会逐步停止。

预置并发支持并发实例按配置预先启动，同时云函数平台不会主动回收这些实例，会尽可能地保障有相应数量的可以处理请求的并发实例。您可通过此功能，为函数的指定版本设定预置并发额度。通过配置预置并发，可预先进行计算资源的准备，降低冷启动、运行环境初始化及业务代码初始化引起的耗时。下图模拟了函数在处理业务流量峰值的预置并发的真实情况。

场景压测

场景1：高 QPS 短运行时长

此类场景下，QPS 较高单次请求运行时间较短，业务在冷启动的一两秒会有并发高峰。接下来我们通过测试观察流量逐步切换或配置预置并发是否能够缓解冷启动并发高峰。

业务情况

压测任务

我们计划分为三个压测任务，分别对应：完全冷启动、逐步切流量、配置预置并发。
每次压测任务都需要从冷启动开始，不能有热实例在；无其他函数影响。

压测目标

高 QPS 的业务在冷启动的一两秒会有并发高峰，通过流量逐步切换或配置预置并发可以缓解冷启动并发高峰。

压测配置

结论

综上，在高 QPS 短运行时间的场景，使用流量逐步切换可以缓解冷启动并发高峰，同时通过预置并发解决客户认为初始化过程（包含函数冷启动）时间过长的问题。

场景2：重计算长时间运行

业务情况

压测目标

长时间计算任务的平均 QPS 不高，但由于计算时间长，大量实例处于运行状态，导致云函数的并发很高。此压测场景希望看到云函数在处理大量较长时间运行任务的时候，任务的调度和处理速度。

压测配置

压测任务

每次压测任务都需要从冷启动开始，不能有热实例在；无其他函数影响。

结果分析

4000消息更能印证2000消息时的结论，前两分钟因为之前的函数没有释放，所以冷启动数和函数请求数是一致的，后续冷启动数和函数请求数增长基本保持一致。

结论

长初始化、长运行时间的业务能够稳定运行，系统能够随着请求数瞬时的完成扩缩容。

场景3：异步消息处理

业务背景

使用云函数做异步消息处理的场景较多，这里取运行100ms作为平均值。

压测目标

异步消息的消费情况与生产相关，我们假设已经有大量的消息堆积，查看云函数的消费情况。其中会包括消费过程中受到并发限制而后重试的情况，您可以通过灵活调整函数的保留并发，从而控制云函数的消费速度，也就是对下游后台的压力。

压测配置

压测任务

每次压测任务都需要从冷启动开始，不能有热实例在。

结果分析

1. 1000并发配额提升到2000并发配额时，能看到函数的处理速度，包括函数并发等明显提升，所以在大量异步消息时提高并发配额可以提升消息处理速度。
2. 2000并发配额提升到4000时，消息处理速度和函数并发量也有提升，但总体处理时间也在2分钟内，说明100w条异步消息时，4000肯定也能提升，但2000配额基本已满足场景需求。
3. 4000并发配额时会有 burst 超限的问题，因为并发配额是4000，burst 是2000，所以大量消息时肯定会有超限的情况发生。

结论

大量异步消息场景，提升函数并发配额，能明显提升消息处理速度，符合预期。
您可以灵活控制函数并发，进而控制异步消息的消费速度。

注意事项

• 内测期间，预置并发能力不计费。预计2021年11月正式发布，届时处于空闲的预置并发实例会收取少量费用，处理请求的实例会按照请求的实际执行时间进行费用计算，详情见 计费概述。