Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

設定佇列轉送、限制和重試

Cloud Tasks 可讓您定義佇列層級的轉送、調度頻率限制和重試行為，藉此管理工作執行。您可以在建立佇列或更新現有佇列時，調整這些設定。

gcloud tasks queues create 和 gcloud tasks queues update 都使用相同的旗標來設定佇列參數，而 gcloud tasks queues update 也支援 --clear-* 旗標，可將參數重設為預設值。

在佇列層級設定驗證會覆寫任務層級的驗證。詳情請參閱「使用 HTTP 目標任務搭配驗證權杖」。

設定佇列層級轉送

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

佇列層級轉送適用於：

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

限制

佇列層級轉送與 Cloud Key Management Service (Cloud KMS) 客戶自行管理的加密金鑰 (CMEK) 不相容。如果啟用 CMEK，則無法執行下列操作：

在具有佇列層級轉送功能的佇列中建立工作
套用佇列層級轉送

設定 HTTP 任務的佇列層級轉送

您可以在建立或更新佇列時，設定佇列來覆寫工作層級轉送。如要設定佇列層級轉送，請將佇列的 uriOverride 參數設為偏好的路徑。根據預設 (uriOverrideEnforceMode 設為 ALWAYS)，佇列層級轉送會覆寫任務層級轉送。您也可以將 uriOverrideEnforceMode 設為 IF_NOT_EXISTS，這樣只有在工作未指定自己的 URI 元件時，才會套用佇列層級轉送。

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

執行下列指令，暫停佇列：
```
gcloud tasks queues pause QUEUE_ID \
    --location=LOCATION
```
更改下列內容：
- QUEUE_ID：佇列 ID。
- LOCATION：佇列的位置。
更新或移除佇列層級轉送。
- 如要更新佇列層級轉送，請將 uriOverride 參數設為更新後的路徑 (或將 --http-uri-override 旗標傳遞至 gcloud tasks queues update)。
- 如要移除佇列層級轉送，請按照下列步驟操作：
  - Google Cloud CLI：使用 --clear-http-uri-override 旗標執行 gcloud tasks queues update：
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --clear-http-uri-override
```
  - REST API：使用空白 JSON 物件 ({}) 傳送佇列的 patch 要求，並將 updateMask 查詢參數設為 httpTarget.uriOverride (或 httpTarget，清除所有佇列層級的 HTTP 目標設定)。
  - RPC API：針對 Queue 傳送 UpdateQueueRequest，並指定 queue.name、取消設定 http_target.uri_override，以及將 update_mask 參數設為 http_target.uri_override (或 http_target，以清除所有佇列層級的 HTTP 目標設定)。
下列範例使用 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：佇列要轉送至的新主機。
等待一分鐘。

新設定最多可能需要一分鐘才會生效。等待佇列恢復，有助於防止工作以舊設定調度。

執行下列指令，恢復佇列：

gcloud tasks queues resume QUEUE_ID \
    --location=LOCATION

執行下列指令，確認佇列已設定成功：
```
gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION
```
輸出內容應包含您設定的 httpTarget 轉送覆寫。

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

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

設定佇列層級轉送，並覆寫任何任務層級轉送：
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --routing-override=service:SERVICE,version:VERSION
```
更改下列內容：
- QUEUE_ID：佇列 ID (簡稱)。
- LOCATION：佇列的位置。
- SERVICE：負責處理工作的 App Engine worker 服務。
- VERSION：應用程式版本。
舉例來說，如果您設定 worker 服務來處理佇列中的所有工作，可以將流量轉送至該服務和預設版本：
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --routing-override=service:SERVICE
```

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

gcloud tasks queues describe QUEUE_ID \
    --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

如要移除佇列層級轉送，請執行下列指令：
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --clear-routing-override
```
移除佇列層級轉送後，佇列中的工作和日後新增至佇列的工作，都會套用工作層級轉送。

定義頻率限制

無論是首次嘗試調度工作或重試，速率限制都會決定有效佇列調度工作的最大穩態速率。

執行下列指令，設定佇列可調度的並行任務數量和速率上限：
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --max-dispatches-per-second=DISPATCH_RATE \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
```
更改下列內容：
- QUEUE_ID：佇列 ID (簡稱)。
- LOCATION：佇列的位置。
- DISPATCH_RATE：調度率。這是 bucket 中權杖的更新速率。在工作流程相對穩定的情況下，這相當於工作分派速率。
- MAX_CONCURRENT_DISPATCHES：佇列中可同時執行的工作數量上限。
舉例來說，如果您在建立佇列時未設定任何參數，可以執行下列指令，更新並行任務數量上限：
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES
```

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

gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION

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

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

定義佇列處理速率的方法

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

在這兩種情況下，佇列都會使用權杖 bucket 演算法來控制工作執行速率。每個命名佇列都有一個 bucket，用於存放權杖。

應用程式每次執行工作時，系統就會從值區中移除一個權杖。佇列會繼續處理工作，直到值區中的權杖用盡為止。系統會根據您為佇列指定的 max_dispatches_per_second 速率，持續為值區補充新的權杖。如果佇列包含要處理的工作，且佇列的 bucket 包含權杖，系統會同時處理與權杖數量相同的工作，最多可達您設定的 max_concurrent_dispatches 值。

在已預熱的有效佇列中，不平均的負載可能會導致值區中的權杖數量大幅增加，進而在大量要求送達時，導致處理作業激增。在這種情況下，使用中的佇列實際調度率可能會暫時超過 max_dispatches_per_second 速率，進而耗用系統資源，並與使用者服務要求競爭。如果您使用佇列，根據下游服務相對緩慢的服務水準協議管理調度率，這些突發流量可能會導致 HTTP 429 (Too Many Requests) 或 HTTP 503 (Service Unavailable) 等錯誤。不過，如果佇列是新建立、最近恢復或閒置幾分鐘，就會進入冷啟動或閒置狀態，並逐漸增加至 max_dispatches_per_second，而不是立即突發。如要進一步瞭解冷佇列或閒置佇列的增加速度，請參閱「初始佇列增加速度」。

使用任何 Cloud Tasks API 方法時，您可以使用兩個欄位定義佇列調度率：
- max_dispatches_per_second
- max_concurrent_dispatches
第三個欄位 max_burst_size 是由系統根據您為 max_dispatches_per_second 設定的值計算得出。詳情請參閱「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 會根據您設定的參數，以指數輪詢方式重試工作。工作成功執行後，就會從佇列中移除。在所有情況下，工作保留期限上限也適用。

您也可以選擇指定工作層級的重試設定，覆寫工作的佇列層級重試設定。詳情請參閱「設定工作的重試參數」。

執行下列指令，指定佇列中失敗工作的重試次數上限、設定重試次數的時間限制，以及控管重試間隔：
```
gcloud tasks queues update QUEUE_ID \
    --location=LOCATION \
    --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 (簡稱)。
- LOCATION：佇列的位置。
- MAX_ATTEMPTS：任務的嘗試次數上限，包括首次嘗試。如要允許無限次重試，請將這個值設為 -1。即使達到 MAX_ATTEMPTS 或設為 -1，MAX_RETRY_DURATION 仍會套用。
- MAX_RETRY_DURATION：重試失敗工作的最長時間，從首次嘗試工作時算起。值必須是以「s」結尾的字串，例如 5s。如要指定無限期，請將此值設為 0s。即使達到 MAX_RETRY_DURATION 或設為 0s，MAX_ATTEMPTS 仍適用。
注意：如果您指定無限次嘗試 (MAX_ATTEMPTS 為 -1) 和無限時間長度 (MAX_RETRY_DURATION 為 0s)，則工作會重試，直到達到工作保留上限。否則，Cloud Tasks 只會在兩項條件都符合或工作成功後，才會停止重試。如果任務已嘗試 MAX_ATTEMPTS 次，且 MAX_RETRY_DURATION 時間已過，系統就不會再嘗試執行，並會刪除任務。
- 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 資源參考資料。

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

gcloud tasks queues describe QUEUE_ID \
    --location=LOCATION

輸出內容應包含您設定的 retryConfig 參數：

retryConfig:
  maxAttempts: MAX_ATTEMPTS
  maxBackoff: MAX_INTERVAL
  maxDoublings: MAX_DOUBLINGS
  maxRetryDuration: MAX_RETRY_DURATION
  minBackoff: MIN_INTERVAL

後續步驟

瞭解如何建立 HTTP 目標工作。
瞭解如何建立 App Engine 工作。
如要進一步瞭解佇列管理，請參閱 RPC API 參考資料。
如要進一步瞭解佇列管理，請參閱 REST API 參考資料。

設定佇列轉送、限制和重試 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

設定佇列層級轉送

限制

設定 HTTP 任務的佇列層級轉送

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

定義頻率限制

定義佇列處理速率的方法

設定重試參數

後續步驟

設定佇列轉送、限制和重試