如何使全局变量在多个 google appengine 实例上保持不变？

Posted 2023-04-18

【中文标题】如何使全局变量在多个 google appengine 实例上保持不变？

【英文标题】：How to keep global variables persistent over multiple google appengine instances?

【发布时间】：2012-01-26 20:08:12

【问题描述】：

我们的情况如下： 我们正在开展一个学校项目，其目的是让多个团队带着智能手机在城市中四处走动，边走边玩城市游戏。 因此，我们可以让 10 个活跃的智能手机在城市中四处走动，都发布他们的位置，并从谷歌应用引擎请求数据。

有人在浏览器后面，看着所有这些团队四处走动，并向他们发送消息等。

我们正在使用 google appengine 提供的数据存储来存储这些团队发送和请求的所有数据，存储消息并检索它们等。 然而，我们很快发现我们的最大读写限制在哪里，因此我们寻找一种解决方案，能够在不使用谷歌提供的任何有限资源的情况下检索定期更新（这花费了最多的读写）。很明显，因为这是一个学校项目，我们不想为更多的读取和写入付费。

将这些信息存储在全局变量中似乎是一种简单快捷的解决方案，确实如此……但是当我们开始真正测试时，我们注意到我们的一些数据丢失了，然后又重新出现了。事实证明，这是因为对云的请求如此之多，以至于创建了一个新实例，而实例并没有保持这些全局变量的持久性。

所以我们的问题是： 我们能否以某种方式确保这些全局变量在每个运行的 google appengine 实例上始终相同。 要么 我们是否可以限制曾经运行的实例数量，无论对“1”执行了多少请求。 要么 是否有另一种方法以更好的方式存储这些数据，而不使用数据存储和不使用全局变量。

【参考方案1】：

您应该使用内存缓存。如果使用 ndb（新数据库）库，可以自动缓存查询结果。显然这不会大大改善您的写入，但应该会显着提高您可以执行的读取次数。

您需要使用数据存储来支持它，因为数据可以随时从内存缓存中弹出。如果您愿意承担丢失更新的（小）机会，则可以使用 memcache。您可以执行一些操作，例如在数据存储中仅存储一个消息 ID，并让控制器定期验证每个消息 ID 在 memcache 中是否有相应的条目。如果缺少一个，控制器将需要重新输入它。

【讨论】：

谢谢。我们将尝试使用内存缓存，问题主要出在我们的读取中，因此希望这能解决我们的问题。在我们尝试实现谷歌提供的 memcache 机制后，我会报告link

【参考方案2】：

有趣的问题。首先是一些坏消息，我认为没有更好的数据存储方式；不，您将无法阻止新实例的生成，不，您不能使单独的实例始终具有相同的数据。

您可以做的是让实例周期性地与数据存储中的主记录同步，通过智能选择频率并一次性下载/上传信息，您可以将读/写次数限制在一个级别这对你有用。不过，这完全是在拼凑领域。

尽管找到了几乎所有其他东西的配额，但我找不到免费读/写的限制，所以它们可能小得离谱，但事实上你只用 10 部智能手机就能达到这些限制对我来说是一个危险信号。您确定智能手机正在以合理的频率被轮询（或呼入）吗？听起来您可能会不必要地锤击它们。

【讨论】：

免费读取量是每天05万次调用，我打算尝试使用memcaching来解决我的问题，主要是读取量，而不是写入量. （免费写入量也是每天 5 万次调用）

【参考方案3】：

考虑使用 jabber 协议来进行对等方之间的通信。免费限制是相当高的水平。

【参考方案4】：

首先，正如 Tim Delaney 所说，一定要使用 memcache。仅此一项就可能解决您的问题。

如果没有，您应该考虑推送模型。优点是您的客户不会一直要求您提供新数据，只有在实际发生变化时才要求您提供新数据。如果更新足够小，您可以在推送消息中传递它，那么您无需担心所有这些客户端的数据存储读取内存缓存未命中或任何其他重复工作：您在数据更改时读取一次数据，然后把它推给每个人。

第一个推送选项是C2DM (android) 或APN (ios)。它们受到发送的数据量和更新频率的限制。

如果您想变得更高级，可以改用 XMPP。这将让您使用（我相信）更大的有效载荷进行更频繁的更新，但可能需要更多的工程。有关起点，请参阅有关 Android 和 iOS 的 Stack Overflow 问题。

玩得开心！