本頁面提供 Cloud Tasks 工作和佇列的說明、使用時機及使用方式。Cloud Tasks 可讓您將可獨立執行的作業從主要應用程式流程中分離出來，並使用您建立的處理常式，以非同步方式傳送這些作業進行處理。這些獨立工作稱為「工作」。舉例來說，您需要更新資料庫來處理使用者要求，但更新作業可能很耗時。將該詳細資料卸載為工作，可讓您更快從要求返回。
卸載的工作會新增至佇列，並保留工作，直到工作順利執行完畢或重試次數用盡為止，之後就會刪除工作。根據初始設定，佇列也可以做為調度流程控制項。您建立及設定佇列，然後由 Cloud Tasks 服務管理。新增工作後，佇列會指派工作，並確保工作站能可靠地處理工作。這項服務會處理與該程序相關的複雜問題，例如使用者面臨的延遲費用、伺服器當機、資源用量限制和重試管理。
Cloud Tasks 設計為提供「至少一次」的遞送；也就是說，如果成功新增了工作，佇列就會至少遞送工作一次。在極少數情況下，可能會發生多次執行工作的情況，所以必須確保您的程式碼在重複執行時不會有任何有害的副作用。處理常式應為冪等。
工作本身會包含唯一名稱與設定資訊，並可能包含來自初始要求的任何資料 (稱為酬載)，要有這些資料才能處理要求。由於酬載是透過要求本文傳送，包含酬載的工作必須使用 POST 或 PUT 做為 HTTP 方法。
如要使用 Cloud Tasks API 存取 Cloud Tasks 服務，您必須擁有 Google Cloud 專案。
功能
使用 Cloud Tasks 時，您可以透過下列控制項調派非同步工作項目：
- 排定特定傳送時間
- 管理放送率
- 設定重試行為
- 存取及管理佇列中的個別工作
- 啟用工作重複資料刪除功能
一般工作流程
一般工作流程如下所示：
- 建立工作站來處理工作。
- 建立佇列。
- 透過程式建立工作，並將工作加入佇列。
- Cloud Tasks 服務會向原始應用程式傳回「OK」。這表示工作已成功寫入 Cloud Tasks 儲存空間，因此建立工作要求兼具高可用性和耐久性。
- 將工作傳送到工作站。
- 工作站處理工作。
- 為完成序列，工作站會將 2xx 成功狀態碼傳回 Cloud Tasks 服務。
工作提交到佇列後，初始要求就無法再使用任何資料。
用途
常見用途包括：
- 將可能緩慢執行的背景作業 (例如將資料庫更新到工作站) 委派出去，加快使用者的回應時間
- 在發生非預期的實際工作環境事件時保留要求
- 從主要的使用者流程中移除非使用者端工作，以應付流量遽增的情況
- 管理第三方 API 呼叫率
具有 HTTP 目標的 Cloud Tasks 佇列
如果是通用 HTTP 目標，Cloud Tasks 服務會根據工作設定方式，將工作要求轉送到位於任何通用 HTTP 端點的工作站。這個端點可能位於 Cloud Run 函式、Cloud Run、GKE、Compute Engine，甚至是內部部署的網路伺服器，具體取決於工作設定。這些佇列會以穩定的頻率來分派要求 (這個頻率可供設定)。如此將可確保工作穩定執行：當工作成功完成時，所有工作站都必須在預設的 10 分鐘逾時期限前，傳送 HTTP 回應碼 (200 到 299) 到 Cloud Tasks 服務；逾時期限最多為 30 分鐘。如果傳送的回應不同或沒有回應，系統會重試工作。
目標必須管理工作站的擴縮作業，並在工作完成後清除工作。
如果目標需要驗證，您必須設定兩個服務帳戶，一個用於應用程式 (用戶端)，另一個用於佇列本身。兩個帳戶都必須獲得必要權限，且工作要求中必須包含用戶端服務帳戶的 ID。詳情請參閱「建立 HTTP 目標工作」一文。
使用 App Engine 目標的 Cloud Tasks 佇列
Cloud Tasks 與下列 App Engine 環境相容：
- App Engine 標準環境第二代執行階段
- App Engine 彈性環境
使用 Task Queue 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 參數。
系統會根據工作設定方式 (在少數情況下是根據佇列本身的設定方式) 轉送工作。佇列會以穩定的頻率來分派要求 (這個頻率可供設定)。如此將可確保工作穩定執行：當工作成功完成時，所有工作站都必須根據服務的執行個體資源調度類型，在期限前傳送 HTTP 回應碼 (200 到 299) 到 Cloud Tasks 服務；自動資源調度類型的期限為 10 分鐘，手動資源調度類型的期限則可多達 24 小時。如果傳送的是其他回應，或沒有回應，則表示在重試工作。
由於處理常式是 App Engine 的一部分，Cloud Tasks 服務本身可以執行大部分的工作程序管理作業，根據流量多寡調整工作站數量，並在工作完成後刪除工作。
依目標支援的區域
如果目標是 HTTP/S 端點，Cloud Tasks 適用於 Cloud Tasks 的所有支援 Google Cloud 地區。
如果目標是位於目前專案中的 App Engine 應用程式：
如要建立以 App Engine 為目標的工作，只能在專案的 App Engine 區域中進行。
一個 Google Cloud 專案只能包含一個 App Engine 應用程式，且應用程式建立後，即無法變更應用程式所在的地區。
App Engine 具有「地區性」，這表示執行您應用程式的基礎架構位於特定地區。如要跨多個區域分配運算和佇列，請改為指定 HTTP/S 端點。
如果您未使用 App Engine 做為目標，就不需要部署 App Engine 應用程式，而且可以停用任何現有的 App Engine 應用程式。
重要詞彙
下列詞彙說明 Cloud Tasks 的主要功能。
| 字詞 | 定義 |
|---|---|
| 佇列 | 具有相同目標類型的一系列工作，由單一設定管理。 |
| 目標類型 | 工作的處理位置與方式。 |
| 工作站 | 處理工作的服務。 |
| 嘗試 | 執行工作的嘗試。 |
| 嘗試分派 | 當 Cloud Tasks 將工作傳送到目標時。 |
| 嘗試回應 | 工作人員的回應，指出與工作相關聯的工作已成功完成或失敗。 |
| 重試 | 嘗試執行某項工作多次。重試次數是使用重試參數設定。 |
| 頻率限制 | 佇列的頻率限制。 |
觀測能力
您可以運用 Google Cloud Observability 提供的監控、記錄和診斷工具，監控及分析 Cloud Tasks 活動和成長情況。詳情請參閱「Cloud Tasks 的可觀測性」。