借助 Cloud Tasks，您可以针对特定的队列执行行为和服务限制进行设计，从而构建弹性异步系统。您可以通过考虑至少一次传送、系统限制和目标资源容量来防止处理瓶颈和意外延迟。
执行顺序
除了计划在未来运行的任务之外，任务队列在执行顺序上完全独立于平台。不保证或尽力尝试以任何特定顺序执行任务。具体而言：除非队列完全清空，否则无法保证旧任务会执行。在许多常见情况下，较新的任务会比旧任务更早执行，并且与此相关的模式可能会在不另行通知的情况下发生变化。
执行延迟
由于内部系统重启，Cloud Tasks 执行偶尔可能会出现轻微延迟，通常会持续几分钟。任务会延迟，但不会丢失。这些是系统级事件，没有解决方法。这些事件不会被记录，并且其发生没有固定的时间表。
重复执行
Cloud Tasks 旨在实现严格的“仅执行一次”语义。但是，如果必须在保证执行和重复执行之间做出设计权衡，该服务会倾向于保证执行。因此，确实会发生非零数量的重复执行。 确保您的应用能够妥善处理重复执行，以免导致意外失败。在生产环境中，超过 99.999% 的任务仅执行一次。
资源限制
立即处理队列时最常见的积压问题就是耗尽目标实例上的资源。如果您尝试在每秒只能处理 10 个请求的前端实例上每秒执行 100 个任务，则会产生积压。这通常以两种方式之一表现出来，这两种方式通常都可以通过增加处理请求的实例数量来解决。
退避时间错误和强制执行速率
过载的服务器可能会开始返回退避错误：HTTP 503（对于 App Engine 目标）或 HTTP 429 或 5xx（对于外部目标）。Cloud Tasks 会通过减慢执行速度来应对这些错误，直到错误停止。这种系统限制可防止工作器过载。您的设置不会更改。
系统会在以下情况下进行限制：
Cloud Tasks 会在发生所有错误时退避。通常，Cloud Tasks 会使用
retry_config中指定的退避时间。但是，如果工作器返回 HTTP429 Too Many Requests、503 Service Unavailable或5xx错误响应，或者错误率较高，Cloud Tasks 会强制执行较低的分派速率，并考虑Retry-AfterHTTP 响应标头中指定的重试延迟时间。在错误停止且目标处理程序返回 HTTP2xx响应后，队列会逐渐将其强制执行的调度速率恢复到正常水平。为了防止流量峰值并平滑负载的突然增加，Cloud Tasks 会在队列新创建、暂停后恢复或在没有活跃分派的情况下空闲几分钟后逐渐增加分派。当有大量任务突然可供分派时，例如在任务创建高峰期或许多任务安排在同一时间时，也会发生这种逐步增加的情况。从冷启动或空闲状态开始，Cloud Tasks 会以较低的基准速率开始分派，并在定期评估间隔内逐步提高强制分派速率。只要队列需求保持饱和且目标处理程序返回 HTTP
2xx响应，速率就会继续逐步提高，直至达到您配置的max_dispatches_per_second速率。如需详细了解冷启动或空闲启动以及管理恢复的队列，请参阅初始队列启动和目标过载。
延时峰值和最大并发数
过载的服务器还会出现延迟时间大幅增加的响应。
在这种情况下，请求保持打开状态的时间会更长。由于队列以任务的最大并发数运行，这可能导致队列无法按照预期速率执行任务。如果值设置得太低，导致人为引入速率限制，则提高受影响队列的 max_concurrent_dispatches 值会有所帮助。但增加 max_concurrent_dispatches 不太可能缓解任何底层资源压力。
长时间运行的任务存在预热问题
Cloud Tasks 任务队列会根据之前成功分派的任务数量等因素来提高输出。如果任务处理程序需要相当长的时间（以分钟为单位）来完成任务并返回成功响应，则队列提升速率可能会出现延迟。
查看 5,000 多项任务
如果您有超过 5,000 个任务，则某些任务不会显示在Google Cloud 控制台中。使用 gcloud CLI 查看所有任务。
报告的队列深度指标上限
Cloud Tasks 报告的最大队列深度指标上限为 1,000,000 个任务。此举旨在提升底层任务工作器的性能，不会影响可发送到队列或由队列处理的任务数量。发送到队列的任务如果超出队列深度限制，仍会按预期继续执行。
如需提取超过 1,000,000 个任务的当前队列深度，您可以使用 queues.tasks.list 方法。此方法会返回所有任务并进行分页，以便您汇总数据并执行计数操作。不过，根据队列深度大小，该方法可能会遇到配额限制。
重新创建同名队列
删除队列会永久且不可逆地删除队列中的所有任务，包括已安排的任务以及正在等待执行或重试的任务。您和 Cloud Customer Care 都无法恢复已删除的队列或任务。
删除队列后，您必须等待 3 天才能重新创建同名队列。此等待期可防止在删除时执行的任务中出现意外行为，并避免在删除和重新创建周期内发生内部进程故障。等待期适用于通过任何接口（包括 Google Cloud 控制台、gcloud CLI、REST 或 RPC API 或 Terraform）删除的队列。
在此墓碑窗口期（最长 3 天）内，队列创建请求可能会在不重新创建队列的情况下显示为成功，并且上传包含已删除队列名称的 queue.yaml 文件可能会失败。如需确认已重新创建同名队列，请使用 gcloud tasks queues describe 命令或 projects.locations.queues.get 方法检索该队列。成功的 (200 OK) 响应会确认队列已重新创建。
如需清除任务或修改队列，而不丢失队列或触发 3 天等待期，请清除队列中的所有任务、就地更新队列或暂停队列，而不是删除并重新创建队列。如果您使用 Terraform 管理队列，请在 lifecycle 块中设置 prevent_destroy = true，以防止意外删除队列。
使用安全边界时不支持的目标
如果您已使用 VPC Service Controls 设置了安全边界，则系统会阻止来自 Cloud Tasks 执行的 HTTP 请求访问不受支持的目标，并失败并显示 TARGET_TYPE_NOT_PERMITTED_FOR_VPC 错误代码。如需了解详情，请参阅使用 VPC Service Controls 设置服务边界。
资源位置限制条件
Cloud Tasks 支持限制资源位置；但是，以下区域存在限制：
us-central1us-central2（专用 Google Cloud 区域）
如果您在组织政策中指定了其中一个区域，则必须同时包含 us-central1 和 us-central2，即使您未在这两个区域中创建 Cloud Tasks 资源也是如此。即使您的组织不使用专用区域，您也可以在组织政策中包含区域 us-central2。