Cloud Tasks 可讓您針對特定佇列執行行為和服務限制進行設計，建構彈性的非同步系統。您可以考量至少傳送一次、系統節流和目標資源容量，避免處理瓶頸和非預期的延遲。
執行順序
除了排定在未來執行的工作外，工作佇列的執行順序完全與平台無關。我們不保證或盡力以任何特定順序執行工作。具體來說，除非佇列完全清空，否則無法保證舊工作會執行。在許多常見情況下，較新的工作會比舊工作更早執行，且相關模式可能會在未通知的情況下變更。
執行延遲
Cloud Tasks 執行作業有時可能會因內部系統重新啟動而稍微延遲，通常會持續幾分鐘。工作會延遲，但不會遺失。這些是系統層級事件，無法解決。系統不會記錄這些事件，也沒有固定的發生時間。
重複執行
Cloud Tasks 的目標是嚴格執行「僅限一次」語意。不過，如果必須在保證執行和重複執行之間做出設計取捨，服務會選擇保證執行。因此，重複執行的次數不為零。請確保應用程式能妥善處理重複執行作業，以免發生非預期的失敗。在實際工作環境中，超過 99.999% 的工作只會執行一次。
資源限制
立即處理佇列中之所以會有待處理作業，最常見的原因是目標執行個體的資源用盡。如果前端執行個體每秒只能處理 10 項要求，而您嘗試每秒執行 100 項任務，就會產生待處理項目。這通常會以兩種方式之一呈現，一般來說，只要增加處理要求的執行個體數量，就能解決這兩種問題。
輪詢錯誤與強制執行率
伺服器超載時，可能會開始傳回輪詢錯誤：HTTP 503 (適用於 App Engine 目標)，或 HTTP 429 或 5xx (適用於外部目標)。Cloud Tasks 會減慢執行速度，直到錯誤停止。這項系統節流機制可防止 worker 超載。設定不會變更。
系統會在下列情況下進行節流：
Cloud Tasks 會在發生所有錯誤時退避。一般情況下，Cloud Tasks 會使用
retry_config中指定的輪詢。不過，如果 worker 傳回 HTTP429 Too Many Requests、503 Service Unavailable或5xx錯誤回應，或是錯誤率偏高，Cloud Tasks 會強制降低調度率，並考量Retry-AfterHTTP 回應標頭中指定的重試延遲時間。錯誤停止且目標處理常式傳回 HTTP2xx回應後，佇列會逐漸將強制執行的調度率調回。為防止流量激增並平緩負載突然增加的情況，Cloud Tasks 會在新建佇列、暫停後恢復佇列，或閒置幾分鐘後沒有主動調度時，逐步增加調度。如果突然有大量工作可供調度，例如工作建立量激增，或許多工作排定在同一時間執行，也會發生這種逐步增加的情況。Cloud Tasks 會從冷啟動或閒置狀態開始，以較低的基準速率調度，並在定期評估間隔內逐步提高強制調度速率。只要佇列需求維持飽和，且目標處理常式傳回 HTTP
2xx回應，速率就會持續提高，直到達到您設定的max_dispatches_per_second速率。如要進一步瞭解冷啟動或閒置啟動，以及管理恢復的佇列，請參閱「初始佇列啟動」和「目標超載」。
延遲時間遽增以及並行數量上限
伺服器超載時，延遲時間也可能大幅增加。在這種情況下，要求會維持開啟狀態較久。由於佇列在執行時會受限於並行工作數上限，因此這可能會導致佇列無法依預期速度執行。如果 max_concurrent_dispatches 值設得太低，導致系統人為限制頻率，則提高受影響佇列的該值可能有助於解決問題。不過，增加 max_concurrent_dispatches 不太可能減輕任何潛在的資源壓力。
長時間執行工作的熱機問題
Cloud Tasks 佇列會根據先前成功調度的任務數量，逐步提高輸出量。如果工作處理常式需要相當長的時間 (以分鐘為單位) 才能完成工作並傳回成功回應，佇列的增加速率可能會延遲。
查看超過 5,000 項工作
如果工作數量超過 5,000 項，Google Cloud 控制台不會顯示部分工作。使用 gcloud CLI 查看所有工作。
回報的佇列深度指標上限
Cloud Tasks 回報的最大佇列深度指標上限為 1,000,000 項任務。這項異動旨在提升基礎工作 worker 的效能，不會影響可傳送至佇列或由佇列處理的工作數量。傳送至佇列的工作超過佇列深度限制，仍會照常執行。
如要擷取超過 1,000,000 項工作的目前佇列深度，可以使用 queues.tasks.list 方法。這個方法會傳回所有分頁工作，讓您匯總資料並執行計數作業。不過，視佇列深度大小而定，這個方法可能會受到配額限制。
重新建立同名佇列
刪除佇列會永久且不可撤銷地刪除佇列中的所有任務，包括排定的任務，以及等待執行或重試的任務。您和 Cloud Customer Care 都無法復原已刪除的佇列或任務。
刪除佇列後，必須等待 3 天，才能以相同名稱重新建立佇列。這段等待期可防止刪除時執行的任務發生非預期行為，並避免在刪除和重新建立週期中發生內部程序失敗。無論透過何種介面刪除佇列，包括 Google Cloud 控制台、gcloud CLI、REST 或 RPC API，或 Terraform，都必須等待這段時間。
在這段最長 3 天的墓碑期間，佇列建立要求可能會顯示為成功，但不會重新建立佇列，且上傳包含已刪除佇列名稱的 queue.yaml 檔案可能會失敗。如要確認是否已重新建立同名佇列，請使用 gcloud tasks queues describe 指令或 projects.locations.queues.get 方法擷取佇列。如果收到成功 (200 OK) 回應，代表佇列已重新建立。
如要清除任務或修改佇列，而不遺失佇列或觸發 3 天等待期，請清除佇列中的所有任務、就地更新佇列，或暫停佇列，而非刪除並重新建立佇列。如果您使用 Terraform 管理佇列，請在 lifecycle 區塊中設定 prevent_destroy = true
，以免不小心刪除佇列。
使用安全周邊時不支援的目標
如果您已使用 VPC Service Controls 設定安全 perimeter，系統會封鎖 Cloud Tasks 執行作業對不支援目標發出的 HTTP 要求，並傳回 TARGET_TYPE_NOT_PERMITTED_FOR_VPC 錯誤代碼。詳情請參閱「使用 VPC Service Controls 設定 service perimeter」。
資源位置限制
Cloud Tasks 支援限制資源位置，但下列區域有限制：
us-central1us-central2(私人 Google Cloud 區域)
如果您在組織政策中指定任一區域，則必須同時加入 us-central1 和 us-central2，即使您並未在這兩個區域建立 Cloud Tasks 資源也一樣。即使貴組織不使用私人區域，您也可以在組織政策中加入 us-central2 區域。