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