问题和限制

本页介绍了您在使用 Cloud Tasks 时可能会遇到的一些问题和限制。

执行顺序

除计划在将来运行的任务外，任务队列的执行顺序完全不受平台影响。无法保证或尽力尝试按照特定顺序执行任务。具体来说：除非队列完全清空，否则无法保证先执行旧任务。很多用户都遇到新任务的执行时间比旧任务早的情况，而且没有定式，随时都会改变。

重复执行

Cloud Tasks 力求实现严格的“执行一次”语义。但是，在面临保证执行和重复执行只取其一的情况下，服务宁愿重复执行也要保证执行。因此，系统无法保证完全杜绝重复执行。开发者应采取措施确保重复执行不是灾难性事件。在生产环境中，超过 99.999％ 的任务仅执行一次。

资源限制

立即处理队列时最常见的积压问题就是耗尽目标实例上的资源。如果用户企图在仅可每秒处理 10 个请求的前端实例上每秒执行 100 个任务，就会产生积压。这通常有两种表现形式，其中任何一种一般都可以通过增加处理请求的实例数来解决。

退避时间错误和强制执行速率

过载的服务器会开始返回退避时间错误：HTTP 503（对于 App Engine 目标）或 HTTP 429 或 5xx（对于外部目标）。Cloud Tasks 将减慢执行速度直至错误停止，以此应对这些错误。此系统节流可防止工作器过载。请注意，用户指定的设置不会更改。

在以下情况下会发生系统节流：

  • Cloud Tasks 会针对所有错误进行回退。通常，系统会使用 rate limits 中指定的回退。但是，如果 Worker 返回 HTTP 429 Too Many Requests、503 Service Unavailable 或错误率较高，Cloud Tasks 会使用更高的退避率。系统会考虑 Retry-After HTTP 响应标头中指定的重试。

  • 为防止流量激增并平滑流量的突然增加，当队列新创建或处于空闲状态时，以及如果有大量任务突然可供调度（由于创建任务速率激增、队列取消暂停或同时安排许多任务），调度会缓慢增加。

延时峰值和最大并发数

过载的服务器还会出现延迟时间大幅增加的响应。 在这种情况下，请求保持打开状态的时间会更长。由于队列以任务的最大并发数运行，这可能导致队列无法按照预期速率执行任务。如果该值设置得太低，造成了人为的速率限制，那么为受影响的队列增加 max_concurrent_dispatches 会有所帮助。但增加 max_concurrent_dispatches 不太可能减轻任何潜在的资源压力。

长时间运行的任务的启动问题

Cloud Tasks 队列根据之前成功调度的任务数部分增加其输出。如果任务处理程序用相当长的时间（按几分钟的顺序）完成任务并返回成功响应，则队列提升速率可能存在延迟。

查看超过 5,000 项任务

如果您有超过 5,000 项任务，Google Cloud 控制台中将不会显示部分任务。使用 gcloud CLI 查看所有任务。

重新创建同名队列

如果您从 Google Cloud 控制台中删除某个队列，则必须等待 3 天才能重新创建同名队列。此等待时间可防止在删除时正在执行或等待执行的任务中发生意外行为。同时还可避免删除或重新创建周期中的内部进程失败。