Cloud Tasks 概览

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

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

这些任务本身是由唯一名称和配置信息以及处理请求时所需的初始请求数据(称作负载;可选)组成的。由于负载是在请求正文中发送的,因此这些包含负载的任务必须将 POST 或 PUT 用作其 HTTP 方法。

App Engine 标准环境第一代运行时的用户应通过 App Engine Task Queue API 访问 Cloud Tasks 服务。如需详细了解如何使用此方法,请参阅 Java 8Python 2.7Go 1.9PHP5.5 文档。App Engine 标准环境第二代运行时的用户、柔性环境和其他平台的用户现在可以使用 Cloud Tasks API。

要使用 Cloud Tasks API 访问 Cloud Tasks 服务,您必须有一个项目,其中包含用于托管您创建的 Cloud Tasks 队列的 App Engine 应用。此应用位于特定地区,该地区将用作 Cloud Tasks 请求的 LOCATION_ID 参数,因此请记下该地区。该应用充当开发者创建任何队列所在的位置。基本的 Cloud Tasks 服务本身也在同一位置运行。

使用场景

典型用例包括:

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

使用 HTTP 目标的 Cloud Tasks 队列

如果是通用 HTTP 目标,则 Cloud Tasks 服务会根据任务请求转发给位于任何通用 HTTP 端点上的工作器(如Cloud FunctionsCloud RunGKECompute Engine,甚至是本地 Web 服务器(具体取决于任务的配置方式)。这些队列会以可靠且可配置的速率调度请求。它们可确保任务得到可靠执行,任务成功完成后,所有工作器必须在 10 分钟的截止时间之前向 Cloud Tasks 服务发送一个 HTTP 响应代码 (200-299)。 如果发送了不同的响应,或者没有响应,系统会重试该任务。

基于 HTTP 的队列

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

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

使用 App Engine 目标的 Cloud Tasks 队列

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

基于 App Engine 的队列

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

工作流

一般工作流程如下:

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

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

特性

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

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

条款

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

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

指标

下面预定义的 Cloud Task 指标可通过 Stackdriver 获得:

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