配置 Cloud Tasks 队列

本页介绍了如何使用 Google Cloud SDK 的 gcloud 命令配置 Cloud Tasks 队列

配置 Cloud Tasks 队列

您可以在创建队列时或之后的任何时间配置 Cloud Tasks 队列,该配置将应用于该队列中的所有任务。

配置队列需要注意三个基本方面:

配置路由(仅适用于 App Engine 队列)

队列需要知道包含适当工作器的服务的名称和版本(称为目标)。设置目标有以下三种方式:

  • 不明确设置目标。在这种情况下,队列将使用默认服务
  • 通过在 AppEngineHttpRequest 中设置 AppEngineRouting,在任务中明确声明目标。 如果您想使用默认服务以外的目标,这是首选方法。
  • 通过 appEngineRoutingOverride,明确将队列中所有任务路由至非默认目标。此方法将覆盖任务中可能设置的任何路由。

如需使用 gcloud 设置此非默认队列级路由,从而覆盖任何任务级路由,请执行以下操作:

gcloud tasks queues update [QUEUE_ID] \
    --routing-override=service:[SERVICE],version:[VERSION]

其中:

  • SERVICE 是 App Engine 工作器服务,负责任务处理。
  • VERSION 是应用版本。

例如,如果您设置了名为 worker 的工作器服务来处理队列 barbequeue 中的所有任务,则可以通过调用以下命令路由到该服务和默认版本:

gcloud tasks queues update barbequeue \
    --routing-override=service:worker

Describe 队列:

gcloud tasks queues describe barbequeue

输出应如下所示:

appEngineRoutingOverride:
  host: worker.[PROJECT_ID].appspot.com
  service: worker
name: projects/[PROJECT_ID]/locations/[LOCATION_ID]/queues/barbequeue
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: 1000
  maxDispatchesPerSecond: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

定义速率限制

您可以设置队列可调度的并发任务的最大速率和数量。

gcloud tasks queues update [QUEUE_ID] \
    --max-dispatches-per-second=[DISPATCH_RATE] \
    --max-concurrent-dispatches=[MAX_RUNNING]

其中:

  • DISPATCH_RATE 实际上是存储分区中令牌的刷新速率。 在任务流相对稳定的情况下,这相当于任务被分派的速率。
  • MAX_RUNNING 是队列中可同时运行的任务的最大数量。

例如,如果您在未设置任何参数的情况下创建了名为 barbequeue 的队列,则可以通过调用以下命令来更新最大并发任务数量:

gcloud tasks queues update barbequeue \
        --max-concurrent-dispatches=20

Describe 队列:

gcloud tasks queues describe barbequeue

输出应如下所示:

name: projects/[PROJECT_ID]/locations/[LOCATION_ID]/queues/barbequeue
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: 20
  maxDispatchesPerSecond: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

使用 gcloud 命令和 queue.yaml 定义处理速率

Cloud Tasks API 定义队列处理速率的方法与使用上传 queue.yaml 文件的方法略有不同,即使这两种方法导致队列使用相同的底层机制。

在这两种情况下,队列都使用令牌桶算法来控制任务执行速率。每个命名的队列都有一个用于存储令牌的存储分区。

应用每执行一个任务,系统就会从桶中移除一个令牌。 队列会继续处理任务,直到该队列的令牌桶中再也没有令牌为止。系统会按照您为队列指定的 max_dispatches_per_second 速率不断向令牌桶中补充填充新令牌。如果队列中有要处理的任务,并且队列的令牌桶中存在令牌,则系统同时处理的任务数量与令牌数量相同,最多不超过您设置的 max_concurrent_dispatches 值。

负载不平衡可能会导致存储分区中的令牌数量显着增加,这可能会在随后出现大量请求时导致导致处理量暴增。在这种情况下,您的队列可能会遇到超过 max_dispatches_per_second 速率的实际调度速率,这不仅消耗系统资源还会与用户服务请求争用资源。如果您使用队列管理基于相对较慢的下游服务 SLA 的调度速率,则会导致 HTTP 429(请求过多)或 503(服务不可用)等错误。

当您使用任意 Cloud Tasks API 方法时,您有两个字段来定义队列调度速率:

  • max_dispatches_per_second
  • max_concurrent_dispatches

如上例所示。第三个字段 max_burst_size 由系统根据您为 max_dispatches_per_second 设置的值进行计算。

当您使用 queue.yaml 方法时,可以设置以下全部三个元素

  • max_concurrent_requests,等于 max_concurrent_dispatches
  • rate,等于 max_dispatches_per_second
  • bucket_size,等于 max_burst_size

在大多数情况下,使用 Cloud Tasks API 方法并让系统设置 max_burst_size 可以非常高效地管理请求爆发期。但在某些情况下,具体来说是当所需速率较慢时,可以使用 queue.yaml 方法将 bucket_size 手动设置为较小的值,或者通过 Cloud Tasks 将 max_concurrent_dispatches 设置为较小的值 API 来为您提供更多控制权。

设置重试参数

如果任务未成功完成,Cloud Tasks 将根据您设置的参数,使用指数退避算法重试该任务。您可以指定队列中失败任务的最大重试次数,设置重试尝试的时间限制,以及控制重试之间的时间间隔。

gcloud tasks queues update [QUEUE_ID] \
    --max-attempts=[MAX_ATTEMPTS] \
    --min-backoff=[MIN_INTERVAL] \
    --max-backoff=[MAX_INTERVAL] \
    --max-doublings=[MAX_DOUBLINGS] \
    --max-retry-duration=[MAX_RETRY_DURATION]

其中:

  • MAX_ATTEMPTS 是任务可以尝试的最大次数,包括第一次尝试。您可以将此标志设置为 unlimited 来允许进行无限次重试。
  • MIN_INTERVAL 是重试尝试之间的最短等待时间。 该值必须是以“s”结尾的字符串,如 5s
  • MAX_INTERVAL 是重试尝试之间的最长等待时间。 该值必须是以“s”结尾的字符串,如 5s
  • 若任务连续失败,每次重试之间的时间间隔将加倍,直至此间隔达到一个常量。MAX_DOUBLINGS 是在增量变为常量之前重试的最大次数。
  • MAX_RETRY_DURATION 是重试失败任务的最长时间(从首次尝试任务时算起)。该值必须是以“s”结尾的字符串,如 5s

验证您的队列已配置成功:

gcloud tasks queues describe [QUEUE_ID]

后续步骤