我们从您的初始前提开始，即“我显然不想在每次执行时将其重新加载到内存中”。对我而言，这并非总是正确的说法。如果我实现了缓存技术，那么作为一名程序员，我已经花了很多时间将其正确设置，并引入了错误和维护机会。如果我每次执行节省了100毫秒，那么在这些成本与增加执行时间所节省的成本之间，要实现成千上万次执行盈亏平衡呢？我通常会先采用最简单的方法，并准备在将来监视操作并仅在有必要时提出改进建议。

总而言之，让我们假设您已经确定每秒将要发出不计其数的新文件创建请求并想要进行优化。理解如何最佳使用Cloud Run的关键是它运行可以处理并发请求的整个容器。我相信默认值为80。这意味着，如果创建了80个并发文件，则将仅创建一个容器实例，并且将处理80个并行事件。如果您使用Java进行编码，则意味着80个并发线程都在同一JVM中。每个线程将具有对通用全局变量的并发寻址能力。仅当第81个请求到达并且之前的80个请求都没有完成时，才会产生一个新的Cloud Run容器。

这说明我的第一个“改进”是在首次使用时在JVM中填充高速缓存数据，并保留它们以供以后重用。什么时候填充缓存数据？这将是您的设计选择。您可以在容器首次启动时将其全部填充到前面……如果您知道每个请求都会使用该数据，这将是明智的。另外，如果您有多个可缓存的值，请考虑创建一个包含名称/值对并具有访问器的映射，该访问器返回一个缓存的值（如果存在）或从慢速存储，缓存中检索并返回一个值（如果最初不存在） ）。

关于第一个选项（选项1 ）：

heavyComputation()函数here仅在冷启动时每次创建新的Cloud Run container instance时才会调用（当可并行发送给定请求的最大请求数时）超出了容器实例，因此创建了一个新的实例。

为了解决第二个选项（选项2 ）：

到目前为止，Cloud Run（完全托管）不支持无服务器VPC访问，因此不可能连接到Cloud Memorystore。监视以下Feature Request，以从Cloud Run产品团队获取所有相关信息和更新，以检查何时可以使用此功能。

您可以在此post和前面提到的功能请求中找到一些解决方法。它们基本上包括：

1. Using a Google Kubernetes Engine cluster with Cloud Run。
2. 在Compute Engine上设置Redis实例。