Cloud Tasks 和 Pub/Sub 都可用來實作訊息傳遞和非同步整合操作。不過，雖然兩者功能相似，卻並非完全相同。本指南可協助您為自己的用途選擇合適的產品。
主要差異
Pub/Sub 和 Cloud Tasks 的主要差異在於是否使用隱含或明確叫用。
Pub/Sub 會將事件發布者與訂閱者分離。發布者不需瞭解各自的訂閱者。因此，Pub/Sub 除了保證能確實傳送訊息外，還讓發布者無法控制訊息的傳送方式。這項功能支援「隱含」叫用，使發布者可以透過發布事件，觸發訂閱者執行動作。
相較之下，Cloud Tasks 的目標是明確叫用。發布者可完全掌握執行情況。具體來說，發布者可以指定要提交每則訊息的端點。
此外，Cloud Tasks 也提供 Pub/Sub 發布者無法使用的佇列和工作管理工具，包括：
- 排定特定送達時間
- 控管傳送率
- 精確設定重試作業
- 存取與管理佇列中的個別工作
- 簡化工作建立作業
詳細功能比較
| 功能 | Cloud Tasks | Pub/Sub |
|---|---|---|
| 使用 Webhook 推送 | 是 | 是 |
| 保證至少傳送一次 | 是 | 是 |
| 可設定重試作業 | 是 | 是 |
| 簡化工作/訊息建立作業 | 是 | 否 |
| 排定傳送作業 | 是 | 否 |
| 已訂購的商品 | 否，系統會盡量保留佇列中的工作順序 | 是，透過排序鍵 |
| 確實控管傳送率 | 是 | 提取訂閱者用戶端可以實作流量控制 |
| 使用 API 提取 | 否 | 是 |
| 批次插入 | 是 | 是 |
| 將每則訊息傳送給多個處理程式/訂閱者 | 否 | 是 |
| 工作/訊息保留時間 | 31 天 | 最多 31 天 |
| 工作/訊息的大小上限 | 1 MB | 10 MB |
| 最高放送率 | 每個佇列 500 QPS | 無上限，但須遵守區域輸送量配額 |
| 地理區域可用性 | 地區 | 全球通用 |
| 推送處理程式/訂閱者處理時間上限 | 30 分鐘 (HTTP) 10 分鐘 (App Engine 標準自動調整資源配置) 24 小時 (App Engine 標準手動或基本資源配置) 60 分鐘 (App Engine 彈性環境) |
推送作業為 10 分鐘 |
| 佇列/訂閱數量 | 每個專案每個區域 1,000 個 (可透過配額增加申請提高上限) | 每項專案 10,000 個 |
可設定重試作業的差異
Cloud Tasks 可精確控管工作重試次數，包括嚴格限制嘗試次數和時間長度。Pub/Sub 著重於可靠的傳遞機制，並使用指數輪詢策略和 dead-letter 佇列 (DLQ)，管理未確認訊息的重試作業。
| 功能 | Cloud Tasks | Pub/Sub |
|---|---|---|
| 用途重點 | 確保最終執行特定工作 | 確保訊息傳送至已解除連結的訂閱者 |
| 主要控制項 | 佇列層級和工作層級的重試設定 | 訂閱層級的重試政策和 DLQ |
| 停止重試 | 嘗試次數上限、重試時間長度上限 | 訊息確認、訊息到期或 DLQ 轉移 |
| 嘗試次數上限 | 可明確設定 | 透過 DLQ 傳送嘗試次數上限間接設定 |
| 輪詢微調 | 輪詢時間下限/上限、加倍次數上限 | 指數輪詢政策的最短/最長輪詢時間 |
| 無限次重試 | 可設定，但受限於工作保留期限上限 | 未確認訊息的預設值 (直到過期為止)，由 DLQ 減輕影響 |