说我的应用有一个人们可以添加评论的页面。 在添加每个评论之后说添加了一个taskqueue worker。 因此，如果添加100个注释，则会进行100个任务队列插入。
（注意：上面是一个假设的例子来说明我的问题）
说我想确保插入次数保持为a 最小（所以我没有遇到10k插入限制）
我可以做如下的事情。
a）在添加每条评论时，调用taskqueue.add（name =“stickytask”， URL = “/嗒嗒”） - 由于这是一个命名的taskqueue，如果a，它将不会被重新插入 存在同名的taskqueue。
b）/ blah worker url读取新添加的注释，处理 第一个和 如果存在更多要处理的注释，则返回状态代码 除了200 - 这将确保重试任务并在下次尝试时执行 处理下一个评论 等等。
所以所有100条评论都是通过1或几个任务队列插入来处理的。 （注意：如果有平静 在没有添加新评论和所有评论的活动中 加工比 下一个添加的评论将导致新的任务队列插入。 ）
然而，从文档（参见下面的代码段），它注意到“系统 将逐渐退回“。这是否意味着每个”非200“Http 状态码返回延迟插入下次重试？
来自文档： 如果特定任务的执行失败（通过返回任何HTTP 状态代码不是200 OK），App Engine将尝试重试直到 它成功了。系统将逐渐退回，以免泛滥 您的应用程序请求太多，但它将重试失败 任务至少每天至少一次。
答案 0 :(得分：1)
没有理由假装失败（并导致退避＆amp; c） - 这是一个hacky和脆弱的安排。如果您担心根据新评论简单地安排任务可能会超出任务队列当前的严格限制，那么在商店中“批处理”尚未处理的注释（并且可能还在memcache中，对于潜在的加速，但是，这是可选的）并且当时不安排任何任务。
相反，保持一个cron作业每分钟执行（比如说），这可能会处理一些注释或安排适当数量的任务来处理待处理的注释 - 当你从一个cron作业安排任务时，很容易确保你每天的安排量超过10,000。
不要让任务队列忘记cron也在那里：“批处理”处理的良好架构通常会使用cron作业和排队任务来简化其整体设计。
为了最大化在单个请求中完成的有用工作量（从以太任务排队的任务或cron任务），考虑一种基于monitoring CPU使用率的方法 - 当CPU是限制工作的因素时您可以按请求执行，这可以帮助您在一个请求中完成尽可能多的小型可调度工作单元，这是谨慎可行的。我认为这种方法比等待OverQuotaError，抓住它并快速关闭更为可靠，因为这可能会导致应用程序无法控制其他后果。