我们真的应该在 AWS lambda 运行时重用全局变量吗？

Question

我引用了 here 关于 AWS-lambda 服务性能提示的这段非常阴暗的段落。

根据 AWS 团队的说法：

利用执行上下文重用来提高性能 你的功能。确保任何外部化配置或 存储和引用您的代码检索的依赖项 初始执​​行后在本地。限制重新初始化 每次调用的变量/对象。而是使用静态 初始化/构造函数、全局/静态变量和单例。 保持活动并重用之前的连接（HTTP、数据库等） 在上一次调用期间建立

让我们暂时忽略故意将变量声明为全局、静态并选择单调*的邪恶想法（个人而言，这是最不负责任的建议之一可以给出）我主要关心的是开放连接的使用。

我的问题是：

1. 如果，例如，一个 lambda 调用与另一个之间的连接超时，会发生什么？ AWS 运行时如何“知道”不重复使用该连接？

2. 如果连接被缓冲会发生什么？意思是以前的调用有残留？

3. 这个建议（跨调用重用连接）真的适用于现实生活吗？这对我来说似乎很麻烦。

Answer 1

1. 如果，例如，一个 lambda 调用与另一个之间的连接超时，会发生什么情况？ AWS 运行时如何“知道”不可以重复使用 那个联系？

2. 如果连接被缓冲会发生什么？意思是以前的调用有残留？

AWS 运行时根本不“知道”如何处理它。您的 Lambda 函数需要通过检查连接是否仍然有效并在它不再有效时处理这种情况来了解这一点。

1. 这个建议（跨调用重用连接）在现实生活中真的有效吗？这对我来说似乎很麻烦。

鉴于 AWS Lambda 运行时环境的实际情况，如果您关心的是减少 Lambda 函数调用的冷启动时间，此建议绝对有效。但是，它肯定会导致与关系数据库的连接等问题，这就是亚马逊发布AWS Aurora Data API 的原因。

我通常会尝试遵循此建议在 Lambda 函数中缓存数据，例如通过读取数据库表或将 S3 对象加载到内存中来初始化数据结构，但我发现全局范围的数据库连接存在问题在 Lambda 函数中比它的价值更麻烦，但如果你的 Lambda 函数有非常频繁的调用，它对你来说可能是值得的。