GAE 标准迁移到 Go 1.11/1.12 后的缓存答案

【问题标题】：Caching after GAE standard migration to Go 1.11/1.12GAE 标准迁移到 Go 1.11/1.12 后的缓存
【发布时间】：2021-07-29 22:41:46
【问题描述】：

我几乎完成了基于google's instructions.的迁移

不用调用应用引擎库真是太好了。

但是，现在我必须替换对 app-engine-standard memcached 的调用。

指南如下：“要在 App Engine 上使用 Memcache 服务，请使用 Redis Labs Memcached Cloud 而不是 App Engine Memcache。”

这是我唯一的选择吗？第三方？如果选择 GCE，他们甚至不会在页面上列出定价。

我还看到在标准环境操作指南中有一个关于Connecting to internal resources in a VPC network.的指南

从该链接中提到了 Cloud Memorystore。如果在 GAE 标准上建议或可能这样做，我找不到任何示例。当然以前不可能，但现在 GAE 标准变得更加“标准”了，我认为应该可以？

感谢您对最佳前进方向的任何建议。

【问题讨论】：

几个月过去了，你做了什么？
目前在没有缓存的情况下离开，希望音量保持足够低，直到我有时间解决这个问题（加速的早期阶段）。我的计划是延迟足够长的时间让谷歌想出一些东西！或者在 vm 上安装 bitnami redis 或其他一些基于 go 的解决方案。 GAE 标准现在超级开放，因此实际上很容易连接。

标签： google-app-engine

【解决方案1】：

Memorystore 似乎是 Google 的替代品： https://cloud.google.com/memorystore/

您可以使用本指南连接到它： https://cloud.google.com/appengine/docs/standard/go/using-memorystore

唉，没有免费配额，每天的费用约为 1.20 美元/GB。

因此，如果您的数据没有改变，并且一次需要少于 100MB 的缓存，那么第一个答案可能会更好（免费）。此外，您的数据不会爆炸实例，因为您可以控制缓存的最大大小。

但是，如果您的数据发生变化或需要更多缓存，MemoryStore 是 MemCache 的更直接替代品 - 只是要花钱。

【讨论】：

这反映了我在 5 月份从 Google 得到的答案。也许现在已经脱离了“阿尔法”？ Google：“3. Cloud Memorystore 是一项完全托管的 Google 服务，可提供快速的内存数据存储 [7]。要将此产品与 App Engine 标准一起使用，需要使用 VPC 网络连接器，该连接器目前处于测试版中[8][9]. 此时 VPC 连接器和 App Engine 必须在同一个区域，并且 VPC 连接器唯一可以使用的区域是 us-central1。有一个 Go 客户端库可用，但目前处于 alpha所以它不稳定，很可能会改变[10]。”
终于出官方指南了。这似乎是现在的正确答案！ cloud.google.com/appengine/docs/standard/go/using-memorystore（可以编辑您的答案以包含此链接而不是连接-vpc？）
"每天 1.20 美元/GB，没有免费配额。"他们实际上是按 GB 收费（最低 1GB），还是如果我总共只使用 100MB，我的收费会低于这个？

【解决方案2】：

我一直在考虑这个问题。第二代实例有两倍的内存，所以如果不需要全局缓存（如项目一旦创建就不会更改 - （使用它们的 sha256 命名项目）），您可以运行自己的本地线程安全内存缓存（例如 https://github.com/dgraph-io/ristretto ) 并为其分配一些额外的内存。它会比 Memcache 更快，因此可以更快地处理请求，同时保持较低的实例数量。您可以通过在实例之间使用 pub/sub 来将确实发生变化的数据设为全局，但我认为这需要更多的工作。

【讨论】：

那么你认为这是每个实例吗？我想它可以在相当稳定的流量下很好地工作，否则我猜如果实例被定期创建和关闭，你会输掉，因为在这些情况下数据不会持续存在？
每隔几分钟运行的 cron 作业将保留一个实例并且它的缓存处于活动状态。但是，如果您需要 Cron，您可能无论如何都没有获得足够的流量来超出免费查询限制。但是，由于有大量高负载零星流量，这仍然是减少查询的重大胜利。
如果这个答案不可接受，你能告诉你你在找什么吗？
我认为这是一个非常有趣的答案，我很感激。在规模上，我可以看到缓存中有大量数据会导致实例爆炸。此外，在我看来，应用引擎标准的卖点和原则之一应该是快速扩展和缩减，依赖于无状态服务设计。所以这种违反了。我想我想要的答案需要像 memorystore 或 redis 那样可扩展。

【解决方案3】：

为了方便迁移到 1.12，我一直在考虑使用这个解决方案：

使用 1.11 运行时创建专用应用。
设置 twirp 端点以充当所有已弃用的应用引擎服务（memcache、邮件、搜索...）的代理

【讨论】：