本文旨在解释 AWS Lambda 函数运行时间看似不受冷启动影响的现象。通过分析实际案例和参考资料，揭示了 AWS Lambda 的主动初始化机制，阐述了该机制如何使得部分函数调用避免了冷启动带来的延迟，从而导致整体运行时间与预期不符。文章将提供相关背景知识，并指导读者如何验证主动初始化是否为影响因素。
理解 AWS Lambda 冷启动
在深入探讨这个问题之前，首先需要理解 AWS Lambda 冷启动的概念。当 Lambda 函数首次被调用，或者在一段时间未使用后再次被调用时，AWS 需要创建一个新的执行环境来运行该函数。这个过程包括下载代码、初始化运行环境、加载依赖项等，被称为冷启动。冷启动会显著增加函数的执行时间，影响用户体验。
案例分析
如问题描述中所示，即使某些 Lambda 函数实例经历了冷启动（n_cold > 0），总体函数 myfunc 的响应时间并没有明显增加，这与冷启动带来的延迟预期相悖。
Ping at 27.11.2023 11:02:23.821 took 527ms. n_cold: 2 total_init: 11531ms
上述日志显示，尽管有两个实例经历了冷启动，总初始化时间为 11531 毫秒，但 myfunc 的总运行时间仅为 527 毫秒。
AWS Lambda 主动初始化
这个现象的主要原因是 AWS Lambda 的主动初始化机制。简单来说，当 AWS 部署 Lambda 函数的新版本或配置更改时，AWS 会主动预置一定数量的执行环境，以应对预期的并发请求。
Aaron Stuyvenberg 在其博客中详细描述了这一机制：Understanding Proactive Initialization。
这种机制的目的是为了减少部署后用户体验的波动。AWS 预测函数在部署后会继续以相似的并发量运行，因此会提前创建一些执行环境。这意味着，并非所有请求都会触发冷启动，部分请求可以直接使用预置的执行环境，从而减少了整体延迟。
如何验证主动初始化
为了确认主动初始化是否是导致问题描述中现象的原因，可以使用 Aaron Stuyvenberg 博客中提供的 Python 示例来检测主动初始化。
简单来说，该方法依赖于检测环境变量 AWS_LAMBDA_INITIALIZATION_TYPE。当该环境变量的值为 provisioned 时，表示该 Lambda 实例是由主动初始化创建的。
以下是一个示例代码片段：
import os
def lambda_handler(event, context):
initialization_type = os.environ.get("AWS_LAMBDA_INITIALIZATION_TYPE")
if initialization_type == "provisioned":
print("This Lambda instance was proactively initialized.")
else:
print("This Lambda instance was initialized on-demand.")
return {
'statusCode': 200,
'body': 'Hello from Lambda!'
}通过在 Lambda 函数中添加上述代码，并观察日志输出，可以确定 Lambda 实例是否是由主动初始化创建的。
总结与注意事项
AWS Lambda 的主动初始化机制能够显著减少冷启动对函数性能的影响，但也可能导致开发者对函数运行时间的理解产生偏差。
注意事项：
- 并发量： 主动初始化的效果在高并发场景下更为明显。
- 部署频率： 频繁的部署可能导致更多的主动初始化，从而影响计费。
- 监控： 建议监控 Lambda 函数的初始化类型，以便更好地理解函数性能。
理解 AWS Lambda 的主动初始化机制有助于开发者更好地优化 Lambda 函数的性能，并准确评估函数的运行成本。
