設定 Cloud Tasks 佇列

您可以在建立 Cloud Tasks 佇列時設定佇列，也可以在之後隨時進行設定。設定會套用到該佇列中的所有工作。

設定佇列有三個基本層面：

設定佇列層級的轉送規則

在佇列層級設定的轉送作業會覆寫在工作層級設定的轉送作業。 如果您想在目標服務前方使用 Cloud Tasks 做為緩衝區，或是需要變更佇列中所有工作的路由，這項功能就非常實用。

佇列層級的轉送適用於：

  • 佇列中的工作
  • 在設定佇列層級轉送作業後新增至佇列的工作

限制

佇列層級的路由與 Cloud Key Management Service (Cloud KMS) 客戶管理加密金鑰 (CMEK) 不相容。啟用 CMEK 後，您就無法執行下列操作：

  • 在具有佇列層級路徑的佇列中建立工作
  • 套用佇列層級的轉送規則

設定 HTTP 工作的佇列層級轉送作業

建立或更新佇列時，您可以設定佇列來覆寫工作層級轉送作業。如要設定佇列層級的轉送作業，請將佇列的 uriOverride 參數設為偏好的路徑。

如要將佇列層級的轉送規則套用至現有佇列，請先暫停佇列，再套用變更，並在套用變更後等待一分鐘，再繼續佇列。

  1. 暫停佇列 執行下列指令：

      gcloud tasks queues pause QUEUE_ID

    將 QUEUE_ID 替換為佇列 ID。

  2. 更新或移除佇列層級的轉送設定。

    • 如要更新佇列層級的轉送作業，請將 uriOverride 參數設為更新後的路徑。

    • 如要使用 REST 或 RPC API 移除佇列層級的轉送，請按照下列步驟操作：

      • REST API：傳送patch要求至佇列，酬載為空白，且 updateMask 參數設為 httpTarget。

      • RPC API：傳送佇列的 updateQueueRequest ，酬載為空白，且 update_mask 參數設為 http_target。

    以下範例使用 REST API 更新工作路由傳送的主機：

    curl -X PATCH -d @- -i \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID?updateMask=httpTarget.uriOverride" << EOF
{
  "httpTarget": {"uriOverride":{"host":"NEW_HOST"}}
}
EOF

    更改下列內容：

    • ACCESS_TOKEN：您的存取權杖。如要取得這項資訊，請在終端機中執行下列指令：

      gcloud auth application-default login
gcloud auth application-default print-access-token

    • PROJECT_ID：您的 Google Cloud 專案 ID。 如要取得這項資訊，請在終端機中執行下列指令： 

      gcloud config get-value project

    • LOCATION：佇列的位置。

    • NEW_HOST：佇列要轉送至的新主機。

  3. 等待一分鐘。

    新設定最多可能需要一分鐘才會生效。等待佇列恢復運作，有助於防止系統使用舊設定指派工作。

  4. 執行下列指令，繼續處理佇列：

    gcloud tasks queues resume QUEUE_ID

設定 App Engine 工作的佇列層級轉送

如要為 App Engine 工作設定佇列層級的轉送，請將佇列的 appEngineRoutingOverride 參數設為偏好的 App Engine 服務和版本。

  1. 設定佇列層級轉送作業，並覆寫任何工作層級轉送作業：

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

    更改下列內容：

    • QUEUE_ID：佇列 ID (簡短名稱)。
    • SERVICE：負責處理工作的 App Engine 工作站服務。
    • VERSION：應用程式版本。

    舉例來說，如果設定工作站服務來處理佇列中的所有工作，您可以轉送到該服務及預設版本：

    gcloud tasks queues update QUEUE_ID \
    --routing-override=service:SERVICE

  2. 執行下列指令，確認佇列已設定成功：

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    將 LOCATION 替換為佇列的位置。

    畫面會顯示如下的輸出內容：

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

  3. 如要移除佇列層級的路由，請執行下列指令：

    gcloud tasks queues update QUEUE_ID \
    --clear-routing-override

    移除佇列層級的路由後，系統會將工作層級的路由套用至佇列中的工作，以及日後新增至佇列的工作。

定義頻率限制

無論分派作業是首次嘗試還是重試，速率限制都會決定佇列可分派工作的最大速率。

  1. 執行下列指令，設定佇列可調度的並行工作數上限和最大速率：

    gcloud tasks queues update QUEUE_ID \
    --max-dispatches-per-second=DISPATCH_RATE \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

    更改下列內容：

    • QUEUE_ID：佇列 ID (簡短名稱)。
    • DISPATCH_RATE：出貨率。這是 bucket 中權杖的重新整理率。在工作流程相對穩定的情況下，這相當於工作調度率。
    • MAX_CONCURRENT_DISPATCHES：佇列中可同時執行的工作數量上限。

    舉例來說，如果您在建立佇列時沒有設定任何參數，可以執行下列指令來更新並行工作數上限：

    gcloud tasks queues update QUEUE_ID \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

  2. 執行下列指令，確認佇列已設定成功：

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    將 LOCATION 替換為佇列的位置。

    畫面會顯示如下的輸出內容：

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

定義佇列處理速率的方法

您可以使用 Cloud Tasks API 或上傳 queue.yaml 檔案，定義佇列處理速率。這兩種方法產生的佇列都會使用相同的基礎機制。

在這兩種情況下，佇列都會使用憑證區塊演算法控制工作執行的速率。每個已命名的佇列都有一個存放憑證的區塊。

每次應用程式執行一項工作時，系統就會從區塊中移除一個憑證。佇列會繼續處理工作，直到區塊中再也沒有憑證為止。系統會依據您為佇列指定的 max_dispatches_per_second 速率，持續在區塊中補充新的憑證。如果佇列含有待處理的工作，且佇列的區塊中含有權杖，則系統會同時處理與權杖數量相同的工作，最多可達您設定的 max_concurrent_dispatches 值。

負載不均可能會導致 bucket 中的權杖數量大幅增加，進而造成處理作業暴增，因為要求暴增時，在這種情況下，佇列的實際調度率可能會超過 max_dispatches_per_second 率，耗用系統資源，並與其他服務使用者的要求產生競爭。如果您使用佇列根據下游服務相對較慢的 SLA 管理調度率，可能會導致 HTTP 429 (要求過多) 或 HTTP 503 (服務無法使用) 等錯誤。

  • 使用任何 Cloud Tasks API 方法時，您有兩個欄位可定義佇列的調度率：

    • max_dispatches_per_second
    • max_concurrent_dispatches

    系統會根據您為 max_dispatches_per_second 設定的值，計算第三個欄位 max_burst_size。詳情請參閱RateLimits 訊息。

  • 使用 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 API 將 max_concurrent_dispatches 設為較小的值，可以提供更多控制權。

設定重試參數

如果工作未順利完成，Cloud Tasks 會根據您設定的參數，透過指數輪詢重試工作。

  1. 執行下列指令，指定佇列中失敗工作的重試次數上限、設定重試工作的時間限制，以及控制每次重試的時間間隔：

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

    更改下列內容：

    • QUEUE_ID：佇列 ID (簡短名稱)。
    • MAX_ATTEMPTS：工作嘗試次數上限，包括第一次嘗試。您可以將此旗標設為 -1，允許無限次重試。請注意，如果 MAX_ATTEMPTS 設為 -1，系統仍會套用 MAX_RETRY_DURATION。
    • MAX_RETRY_DURATION：重試失敗工作的時間上限，從首次嘗試執行工作時起算。值必須是以「s」結尾的字串，例如 5s。如果設為 0，工作年齡就不受限制。請注意，如果 MAX_RETRY_DURATION 設為 0，系統仍會套用 MAX_ATTEMPTS。
    • MIN_INTERVAL：重試嘗試之間的最短等待時間。這個值必須是結尾為「s,」的字串，例如 5s。
    • MAX_INTERVAL：重試嘗試之間等待的時間上限。這個值必須是結尾為「s,」的字串，例如 5s。

    • MAX_DOUBLINGS：失敗工作重試間隔時間加倍遞增到常數之前，要將間隔時間加倍的次數上限。工作重試間隔從 MIN_INTERVAL 開始，然後以雙倍增加 MAX_DOUBLINGS 次，接著以線性方式增加，最後則按 MAX_INTERVAL 的間隔重試，直到 MAX_ATTEMPTS 次為止。

      舉例來說，如果 MIN_INTERVAL 為 10s、MAX_INTERVAL 為 300s，且 MAX_DOUBLINGS 為 3，重試間隔會加倍 3 次，以線性方式增加 2^3 * 10 秒，然後以 MAX_INTERVAL 的間隔重試，直到工作嘗試 MAX_ATTEMPTS 次為止：10 秒、20 秒、40 秒、80 秒、160 秒、240 秒、300 秒、300 秒等。

    如要瞭解更多參數詳細資料，請參閱RetryConfig 資源的 Queue 設定。

  2. 執行下列指令，確認佇列已設定成功：

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    將 LOCATION 替換為佇列的位置。

    輸出內容應包含您設定的重試參數。

後續步驟