在 Cloud Run 中将共享缓存对象存储在哪里？

Question

我正在使用 Cloud Run 创建数据提取管道。每次通过 Pub Sub 将文件放入 GCS 存储桶时，都会调用我的 Cloud Run api。我需要加载一些元数据，其中包含我正在摄取的数据的文本。此元数据很少更改。我显然不想在每次执行时将它重新加载到内存中。我最好的选择是什么？到目前为止，我能够研究的是：

选项一

如果对象的开销很大，您也可以在内存中缓存它们 在每个服务请求上重新创建。从请求逻辑中移动它 到全局范围会导致更好的性能。 https://cloud.google.com/run/docs/tips#run_tips_global_scope-java

在这个链接给出的例子中，heavyComputation 函数是否只在冷启动时被调用一次？如果我需要在元数据更新时偶尔重新触发此功能怎么办。我还发现以下信息令人不安，因为似乎无法保证其他实例会重用该对象。

在 Cloud Run 中，您不能假设保留了服务状态 请求之间。但是，Cloud Run 确实重用了单个容器 实例来服务持续的流量，因此您可以在 全局范围以允许其值在后续使用 调用。任何个人请求是否受益于 这种重用无法提前知道。

选项 2

使用 Redis 或 Cloud Memory Store 之类的东西，只要有变化，就会由云功能更新。并且所有的云运行 api 实例都从 Redis 中拉取元数据信息。这会比选项 1 性能更低还是更高？这还有其他不利方面吗？

如果有其他更好的方法可以做到这一点，我会很感兴趣。

更新 1：我想了更多，因为我的元数据对于每个租户都会有所不同，而且我的云运行代码的每次调用都会为一个租户摄取一个文件，因此将是一个坏主意在每次执行时加载所有租户元数据，即使它被缓存。不过，我可能会在每个租户的项目中运行单独的云运行。

Answer 1

关于第一个选项（选项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 实例。

Answer 2

我们从您的初始前提开始，即“我显然不想在每次执行时将其重新加载到内存中”。对我来说，这并不总是正确的说法。如果我实现了一种缓存技术，那么作为一名程序员，我会花时间让它正确，并引入错误和维护的机会。如果我每次执行节省了 100 毫秒，那么与增加执行时间所节省的成本相比，需要多少数千次执行才能实现收支平衡？我通常会预先采取最简单的方法，并准备好监控未来的运营，并仅在必要时进行改进。

话虽如此，让我们假设您已确定每秒将发出无数个新文件创建请求并希望进行优化。了解如何最好地使用 Cloud Run 的关键在于它运行一个可以处理并发请求的整个容器。我相信默认是 80。这意味着如果创建了 80 个并发文件，则只会创建一个容器实例并处理 80 个并行事件。如果您使用 Java 进行编码，这意味着 80 个并发线程都在同一个 JVM 中。每个线程将具有对公共全局变量的并发寻址能力。只有当第 81 个请求到达并且之前的 80 个请求都没有完成时，才会生成新的 Cloud Run 容器。

这告诉我的是，我的第一个“改进”是在第一次使用时在我的 JVM 中填充缓存数据，并保留它以供后续重用。您何时填充缓存数据？这将是您的设计选择。您可以在容器首次启动时预先填充所有内容......如果您知道数据将用于每个请求，这将是明智的。或者，如果您有多个可缓存的值，请考虑创建一个包含您的名称/值对的映射，并具有一个返回缓存值（如果存在）或从慢速存储、缓存和返回值（如果最初不存在）的访问器)。