本页介绍了您在使用 Cloud Tasks 时可能会遇到的一些问题和限制。
执行顺序
除计划在将来运行的任务外，任务队列没有明确的执行顺序，完全不受平台限制。无法保证或尽力尝试按照特定顺序执行任务。具体来说：除非队列完全清空，否则无法保证先执行旧任务。很多用户都遇到新任务的执行时间比旧任务早的情况，而且没有定式，随时都会改变。
重复执行
Cloud Tasks 力求实现严格的“执行一次”语义。 但是，在面临保证执行和重复执行只取其一的情况下，服务宁愿重复执行也要保证执行。因此，系统无法保证完全杜绝重复执行。 开发者应采取措施确保重复执行不是灾难性事件。在生产环境中，超过 99.999％ 的任务仅执行一次。
资源限制
立即处理队列时最常见的积压问题就是耗尽目标实例上的资源。如果用户企图在仅可每秒处理 10 个请求的前端实例上每秒执行 100 个任务，就会产生积压。这通常有两种表现形式，其中任何一种一般都可以通过增加处理请求的实例数来解决。
退避时间错误和强制执行速率
过载的服务器会开始返回退避时间错误：HTTP 503（对于 App Engine 目标），或 HTTP 429 或 5xx（对于外部目标）。Cloud Tasks 将减慢执行速度直至错误停止，以此应对这些错误。这种系统节流可防止工作器过载。请注意，用户指定的设置不会更改。
在以下情况下，系统会进行节流：
Cloud Tasks 会针对所有错误进行退避。通常使用
rate limits中指定的退避。但如果工作器返回 HTTP429 Too Many Requests、503 Service Unavailable或错误率较高，Cloud Tasks 会使用更高的退避时间速率。系统会考虑Retry-AfterHTTP 响应标头中指定的重试。为防止流量高峰并平滑流量的突然增加，当队列新建或处于空闲状态时，调度会缓慢增加；如果突然有大量任务可供调度（由于创建任务速率激增、队列取消暂停或许多任务同时安排），调度也会缓慢增加。
延时峰值和最大并发数
过载的服务器还会出现延迟时间大幅增加的响应。
在这种情况下，请求保持打开状态的时间会更长。由于队列以任务的最大并发数运行，这可能导致队列无法按照预期速率执行任务。如果该值设置得太低，造成了人为的速率限制，为受影响的队列增加 max_concurrent_dispatches 会有所帮助。但增加 max_concurrent_dispatches 不太可能减轻任何潜在的资源压力。
循序渐进地处理长时间运行的任务
Cloud Tasks 队列根据之前成功调度的任务数部分增加其输出。如果任务处理程序用相当长的时间（按几分钟的顺序）完成任务并返回成功响应，则队列提升速率可能存在延迟。
查看超过 5,000 项任务
如果您有 5,000 多个任务，则部分任务不会显示在Google Cloud 控制台中。使用 gcloud CLI 查看所有任务。
重新创建同名队列
如果您从 Google Cloud 控制台中删除某个队列，则必须等待 3 天才能重新创建同名队列。此等待时间可防止在删除时正在执行或等待执行的任务中发生意外行为。它还可以避免删除或重新创建周期中的内部进程失败。