了解 Cloud Tasks

本页介绍 Cloud Tasks 任务和队列是什么以及何时及如何使用它们。借助 Cloud Tasks，您可以分离出在主应用流之外独立执行的部分工作，并使用您创建的处理程序异步处理这些工作。 这些独立的部分工作称为任务。例如，您需要在处理用户请求时更新数据库，但是更新数据库可能非常耗时。将该详细信息分流为任务就可让您更快地从请求返回。

要点：Cloud Tasks 服务是专为异步工作而设计的。 它无法在任务交付时间上提供强有力的保证，因此不适合用户正在等待结果的交互式应用。

已分流的任务会添加到队列中，此队列会一直保留该任务，直到任务成功执行。根据初始配置，队列还可以充当调度流控制。您可以创建和配置队列，然后由 Cloud Tasks 服务进行管理。一旦添加任务，队列便会分派任务并确保您的工作器会可靠地处理这些任务。 与该过程相关的复杂性（例如，面向用户的延迟成本、服务器崩溃、资源消耗限制以及重试管理）都由服务处理。

Cloud Tasks 旨在提供“至少一次”传送；也就是说，如果成功添加了某个任务，队列将至少传送一次该任务。在极少数情况下，可能会执行多个任务，因此您的代码必须确保重复执行不会产生任何有害的副作用。您的处理程序应该具有幂等性。

任务本身由唯一名称和配置信息组成，以及（可选）处理请求所需的初始请求任何数据（称为载荷）。由于载荷是在请求正文中发送的，因此包含载荷的任务必须使用 POST 或 PUT 作为其 HTTP 方法。

如要使用 Cloud Tasks API 访问 Cloud Tasks 服务，您必须有一个 Google Cloud 项目。

使用场景

典型用例包括：

• 通过将可能缓慢的后台操作（如数据库更新）委派给工作器，加快用户响应时间
• 在发生意外生产事件的情况下，保留请求
• 从主用户流中移除并非面向用户的任务，以帮助顺利应对流量高峰
• 管理第三方 API 调用率

使用 HTTP 目标的 Cloud Tasks 队列

如果是通用 HTTP 目标，Cloud Tasks 服务会根据任务的配置方式将任务请求转发给位于任何通用 HTTP 端点的工作器。此端点可以位于 Cloud Functions、Cloud Run、GKE、Compute Engine，甚至是本地网络服务器（具体取决于任务的配置方式）。这些队列会以可靠且可配置的速率调度请求。它们可确保任务得到可靠执行，任务成功完成后，所有工作器必须在默认超时期限（10 分钟）之前向 Cloud Tasks 服务发送 HTTP 响应代码 (200-299)，上限为 30 分钟。 如果发送了不同的响应，或者没有响应，系统会重试该任务。

目标必须管理工作器的扩缩，并在任务完成后执行清理工作。

如果您的目标需要身份验证，您必须设置两个服务账号，一个用于您的应用（即客户端），另一个用于队列本身。必须为这两个账号授予必要的权限，并在任务请求中添加客户端服务账号的标识符。如需了解详情，请参阅创建 HTTP 目标任务。

使用 App Engine 目标的 Cloud Tasks 队列

Cloud Tasks 与以下 App Engine 环境兼容：

• App Engine 标准环境第二代运行时
• App Engine 柔性环境

目前使用 Task Queue API 的 App Engine 第一代运行时用户可以迁移到 Cloud Tasks。如需了解具体操作方法，请参阅迁离旧版捆绑服务。 不使用捆绑任务服务的 App Engine 第一代运行时用户可以升级到第二代运行时，以使用 Cloud Tasks。

对于 App Engine 目标，Cloud Tasks 服务还会将任务请求转发给处理程序，但此工作器位于 App Engine 中。因此，定位 App Engine 处理程序的所有队列都必须具有 App Engine 应用。处理程序必须在 App Engine 应用运行的区域中运行。此区域还用作 Cloud Tasks 请求的 LOCATION_ID 参数。

系统会根据任务（或不太常见的队列本身）配置方式路由任务。这些队列会以可靠且可配置的速率调度请求。它们可确保任务得到可靠执行，任务成功完成后，所有工作器必须在截止时间之前向此实例中的 Cloud Tasks 服务发送一个 HTTP 响应代码 (200-299)，此截止时间取决于服务的实例扩缩类型：自动扩缩为 10 分钟，手动扩缩最长为 24 小时。如果发送了不同的响应，或者没有响应，则会重试该任务。

由于此处理程序是 App Engine 的组成部分，因此 Cloud Tasks 服务本身能处理任务的大部分流程管理事务，可根据流量扩缩工作器，以及在任务完成后删除任务。

注意：App Engine 命令中名为 europe-west 和 us-central 的两个 App Engine 位置分别称为 europe-west1 和 us-central1。

支持的区域（按目标划分）

如果您的目标是 HTTP/S 端点，那么所有受支持的 Google Cloud 区域都支持 Cloud Tasks。

如果您的目标是位于当前项目中的 App Engine 应用，请执行以下操作：

• 只能在项目的 App Engine 区域中创建以 App Engine 为目标的任务。

• 一个 Google Cloud 项目只能包含一个 App Engine 应用，并且应用创建后，App Engine 应用所在的区域将无法更改。

• App Engine 是区域级的，这意味着运行您的应用的基础架构位于特定区域中。如果要在多个区域之间分配计算和队列，则应改为以 HTTP/S 端点为目标。

• 如果您不使用 App Engine 作为目标，则无需部署 App Engine 应用，并且可以停用任何现有的 App Engine 应用。

Workflows

一般工作流程如下：

1. 创建一个工作器来处理任务。
2. 创建一个队列。
3. 以编程方式创建任务，并将其添加到队列中。
4. Cloud Tasks 服务会向源应用返回 OK。这表示任务已成功写入 Cloud Task 存储区，使创建任务请求具有高可用性和持久性。
5. 任务会传递给工作器。
6. 工作器处理任务。
7. 作为整个工作流程的最后一个步骤，工作器会向 Cloud Tasks 服务返回一个 2xx 成功状态代码。

任务发送给队列后，将不再有任何数据可用于初始请求。

注意：Cloud Tasks API 为 App Engine 任务队列服务提供独立于 App Engine 的接口。可使用 App Engine SDK 访问的队列也可以通过 Cloud Tasks API 访问，反之亦然。

特性

借助 Cloud Tasks，您可以使用以下控件分派异步工作项：

• 安排特定的传送时间
• 管理传送速率
• 配置重试行为
• 访问和管理队列中的各项任务
• 启用任务重复信息删除

条款

下表显示了用于描述 Cloud Tasks 行为各个方面的关键术语。

术语	定义
队列	具有由单个配置管理的同一目标类型的一系列任务。
目标类型	处理任务的位置和方式。
工作器	处理任务的服务。
尝试	尝试运行任务。
尝试调度	Cloud Tasks 向其目标发送目标的时刻。
尝试响应	来自工作器的响应，用于表示与任务关联的工作已成功完成或失败。
重试	多次尝试运行任务。重试次数可通过 RetryConfig 进行设置。
速率限制	队列的速率限制。

指标

使用 Cloud Monitoring 时可使用以下预定义的 Google Tasks 指标。

指标类型 显示名 种类、类型、单位	说明 标签
api/request_count API 请求 DELTA、 INT64、 1	Cloud Tasks API 调用的次数。 api_method： 调用的 API 方法（如 CreateTask）。 response_code： 作为字符串的规范响应代码（如 “ok”）。
queue/depth Beta 版队列深度 GAUGE、 INT64、 1	队列中的任务数量。每 60 秒采样一次。采样后，数据在最长 120 秒的时间内不会显示。
queue/task_attempt_count 任务尝试次数 DELTA、 INT64、 1	队列尝试调度的任务数，按任务响应代码细分。 response_code： 作为字符串的规范响应代码（如“ok”）。
queue/task_attempt_delays 任务尝试延迟 DELTA, DISTRIBUTION, ms	每个计划的尝试时间与实际尝试时间之间的延迟。