Google App Engine - 关于 cron 任务的设计注意事项答案

【问题标题】：Google App Engine - design considerations about cron tasksGoogle App Engine - 关于 cron 任务的设计注意事项
【发布时间】：2019-10-08 22:26:34
【问题描述】：

我正在使用 Google App Engine 开发软件。

我对以下问题的优化设计有一些考虑：我需要定期创建和保存一些实体的快照。

在传统的关系数据库世界中，我会创建插入新摘要记录的数据库作业。

例如，一个工作会为每个活跃用户插入一条记录，其中包含他当前的分数到“userrank”表中，比如每小时。

我想知道在 Google App Engine 中实现这一目标的最佳方法是什么。我知道有 Cron 服务，但它是否允许我们执行将插入/更新数千条记录的作业？

【问题讨论】：

我想这取决于您是否注册免费试用或订阅该服务。在 cron 基础上处理数千条记录听起来你应该是订阅者。你能澄清一下你的状态吗？您是否为 App Engine 时间付费？
应用到一定程度后，我们会订阅服务。但让我问一件事，订阅者是否对请求超时有影响？我不确定他们是否会让我处理数千条记录，即使我为此付费。对吗？
启用计费会引发许多限制，但请求超时不是其中之一。

【解决方案1】：

我想您会发现，无论您的框架是什么，每小时都对每个用户的状态进行快照并不能很好地扩展。更普通的环境会通过让您运行更长的任务来掩盖这一点，但您仍然会达到无法每小时为每个用户的数据拍摄快照的地步。

我的建议是：添加一个“最后一个快照”字段，并将模型的 put() 函数子类化（假设您使用的是 Python；在 Java 中也是如此，但我不知道语法)，这样每当您更新记录时，它都会检查自上次快照以来是否超过一个小时，如果是，则创建并写入快照记录。

为了防止并发更新创建两个相同的快照，您需要为快照指定一个从拍摄快照的时间派生的键名。这样，如果两个并发更新尝试写入快照，一个将无害地覆盖另一个。

要获取给定小时的快照，只需查询比请求时间段更新的最旧快照。另外，由于未对非活动记录进行快照，因此您也可以节省大量空间。

【讨论】：

好点，但这里有一个场景：假设应用程序模拟金融市场。每个用户都持有一份合约组合。用户投资组合的市场价值不仅因为他交易，而且因为所有其他人都交易而改变。所以用户投资组合的当前价值与他的行为无关。这种情况可以做些什么？
很公平。在这种情况下，我认为快照实际运行的时间并不重要 - 您可以在需要时根据历史数据生成过去的快照。在这种情况下，我认为等待路线图上的后台处理支持将是您最好的选择。 Cron 作业不会像 Kiv 建议的那样完全工作，因为你不能有多个“分钟”的 cron，或者周期不到一分钟的 cron。我建议在第一次请求时生成和存储用户的历史数据，但我不肯定你能做到这一点足够快 - 取决于他们的投资组合有多大。

【解决方案2】：

您是否考虑过改用remote api？通过这种方式，您可以获得数据存储的 shell 并避免超时。他们在该链接中演示的 Mapper 类非常有用，我已经成功地使用它对大约 1500 个对象执行批处理操作。

也就是说，cron 也应该可以正常工作。您确实对每个单独请求的时间有限制，因此您不能一次全部浏览它们，但是您可以使用重定向来循环任意数量的用户，一次处理一个用户。如果您需要有关此方法的帮助，文档中应该有一个示例。

【讨论】：

谢谢你，基夫。考虑这个场景：我有 5000 个用户，超时前的 Cron 任务可以处理 100 个用户。这意味着我将不得不调用 Cron url 50 次。如果我这样做，我会在谷歌的通缉名单中吗？同样重要的是，这是一种好的做法吗？关于远程api，您对如何调度远程api执行有什么建议吗？
我认为这不是问题。他们给你的配额非常慷慨，所以请留意你的配额详情，以确保你不会超过。
安排远程 api 执行的一种方法是让您的本地计算机运行一个正常的（非 App Engine）cron 任务，该任务只运行您的远程 api 脚本。不过，这将要求您始终开启本地计算机。
再次感谢您。一旦我们启动并运行应用程序，我们将订阅 GAE。我猜作为付款人不会改变 Cron 超时限制？顺便说一句，GAE 路线图具有用于后台处理的任务队列，我想知道它是否是我需要的。
我不会担心 Cron 超时限制。只要您可以在请求空间中处理一个用户，您就可以每小时调用 5000 次 Cron url 而不会出现任何问题。它完全在您的配额之内，而且他们的系统旨在处理比该负载更多的负载。

【解决方案3】：

我将使用 Cron 作业和循环 url 获取方法的组合，详细信息如下：http://stage.vambenepe.com/archives/549。通过这种方式，您可以捕获超时并开始另一个请求。

总结这篇文章，cron 作业调用您的初始进程，您捕获超时错误并再次调用该进程，掩蔽为第二个 url。您必须在两个 URL 之间进行 ping 操作，以防止应用引擎认为您处于意外循环中。您还需要注意不要无限循环。确保更新循环有一个结束状态，因为如果它永远不会结束，这会让你很快超过配额。

【讨论】：