了解 Cloud Tasks

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

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

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

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

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

特性

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

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

常规工作流程

一般工作流程如下：

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

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

使用场景

典型用例包括：

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

使用 HTTP 目标的 Cloud Tasks 队列

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

基于 HTTP 的队列

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

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

使用 App Engine 目标的 Cloud Tasks 队列

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

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

使用 任务队列 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 的队列

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

按目标划分的支持区域

如果您的目标是 HTTP/S 端点，则 Cloud Tasks 在 Cloud Tasks 的所有 支持 Google Cloud 区域中均可用 。

如果您的目标是位于当前项目中的 App Engine 应用 ：

  • 定位 App Engine 的任务只能在项目的 App Engine 区域中创建。

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

  • App Engine 具有 区域性，这意味着运行您应用的基础架构位于特定区域中。如果您想在多个区域中分配计算和队列，则应改为定位 HTTP/S 端点。

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

任务去重

任务去重是通过为任务分配唯一名称来实现的。如果您尝试创建名称已存在于队列中的任务，则创建请求将失败。这样可以防止同一任务被多次添加。

Cloud Tasks 会记住任务名称，最长可达任务从队列中删除后的 24 小时。在此期间尝试使用相同名称重新创建任务也会导致请求失败。

如果您在创建任务时未提供名称，Cloud Tasks 将为其生成唯一名称，因此无需去重。

关键词

以下术语描述了 Cloud Tasks 的主要功能。

术语 定义
尝试 尝试运行任务。
尝试调度 Cloud Tasks 向其目标发送目标的时刻。
尝试响应 来自工作器的响应，用于表示与 任务关联的工作已成功完成或失败。
handler 负责处理任务的应用代码（也称为 工作器）。当 Cloud Tasks 从队列中调度任务时，它会向目标服务发送请求，而该端点上接收和执行任务的代码就是处理程序。
队列 具有由单个配置管理的同一目标类型的一系列任务。
速率限制 确定队列可以调度的任务速率，无论调度是 首次尝试任务还是重试 。
重试 多次尝试运行任务。重试次数是使用 重试参数设置的。
目标类型 处理任务的位置和方式。您可以定位 HTTP 端点或 App Engine 应用。
任务 您要异步执行的基本工作单元。它表示您添加到队列中的单个独立工作，以便由 Cloud Tasks 在主应用流之外进行处理。
worker 处理任务的服务。请参阅 处理程序。

可观测性

您可以使用 Google Cloud Observability 提供的监控、日志记录和诊断工具来监控和分析 Cloud Tasks 活动和增长情况。如需了解详情，请参阅 Cloud Tasks 中的可观测性。