訂閱者總覽

這份文件提供 Cloud Pub/Sub 中的訂閱運作方式總覽。如需提取及推送傳送訂閱的詳細資料,請參閱提取訂閱者指南推送訂閱者指南

如要接收發佈至主題的訊息,您必須訂閱該主題。只有在訂閱後發佈至主題的訊息才能在訂閱者應用程式中找到。訂閱會將主題連接至訂閱者應用程式,訂閱者應用程式會接收及處理發佈至主題的訊息。主題可以有多個訂閱項目,但特定訂閱項目屬於單一主題。

如要瞭解如何建立及更新訂閱項目,請參閱管理主題與訂閱一文。

至少一次的傳送

Cloud Pub/Sub 會為每個訂閱項目傳送每個發佈的訊息至少一次。這種至少一次的行為有一些例外:

  • 依據預設,無法在最長保留時間 7 天內傳送的訊息會遭到刪除,且無法再存取。這通常會在訂閱者跟不上訊息流程時發生。請注意,您可設定訊息保留時間 (範圍為 10 分鐘至 7 天)。如要進一步瞭解訊息保留設定,請參閱重播與捨棄訊息一文。
  • 一般而言,系統不會提交特定訂閱項目建立前所發布的訊息。因此,若訊息發布至沒有訂閱項目的主題,這則訊息就不會提交給任何訂閱者。

訊息傳送給訂閱者之後,訂閱者必須確認訊息。在訊息發送至待提交狀態,到訂閱者尚未確認的這段期間,系統會將這則訊息視為未完成的項目。Cloud Pub/Sub 會反覆嘗試提交尚未確認的所有訊息。然而,Cloud Pub/Sub 不會嘗試將訂閱者未完成的訊息提交給同一個訂閱上的任何其他訂閱者。訂閱者應該在可設定的限制時間內 (又稱為 ackDeadline) 確認未完成的訊息。一旦超過期限,系統不會再將這則訊息視為未完成的項目,而 Cloud Pub/Sub 會嘗試重新提交訊息。

通常,Cloud Pub/Sub 會以發佈訊息的順序提交每個訊息一次。 但是,有時候不會依順序傳送訊息,或者傳送一次以上。訂閱者通常需要遵循冪等原則來處理訊息,才能進行多次提交。Cloud Dataflow PubsubIO 可讓您只處理一次 Cloud Pub/Sub 訊息串流;PubsubIO 會根據自訂訊息識別碼或 Cloud Pub/Sub 指派的訊息識別碼來刪除重複訊息。您也可以使用服務的標準排序 API,透過 Cloud Dataflow 來依序處理。或者,如要依序處理,您訂閱之主題的發佈者可在訊息中包含順序憑證。詳情請參閱訊息排序一文。

提取或推送傳送

訂閱可以針對訊息傳送使用提取或推送機制,您可以隨時變更或設定機制。

提取訂閱項目

在提取傳送中,您的訂閱者應用程式會向 Cloud Pub/Sub 伺服器發出擷取訊息的要求。

  1. 訂閱應用程式會明確呼叫提取方法,其會要求傳送訊息。
  2. Cloud Pub/Sub 伺服器會回應訊息 (如果佇列為空,則會發生錯誤),以及確認 ID。
  3. 訂閱者會明確呼叫確認方法,使用傳回的確認 ID 來確認接收。

提取訂閱訊息要求流程

推送訂閱

在推送傳送中,Cloud Pub/Sub 會向您的訂閱者應用程式發出傳送訊息的要求。

  1. Cloud Pub/Sub 伺服器會將每個訊息做為 HTTPS 要求傳送至位於預先設定端點的訂閱者應用程式。
  2. 端點會傳回 HTTP 成功狀態碼來確認訊息。非成功的回應表示應重新傳送訊息。

推送訂閱訊息要求流程

Cloud Pub/Sub 會根據它接收成功回應的比例調整推送要求的速率。

下表提供為應用程式選擇適當傳送機制的一些指南。

提取 推送
  • 大量訊息 (超過每秒 1 個許多)。
  • 訊息處理的效率與總處理量很重要。
  • 無法設定含非自行簽署之 SSL 憑證的公開 HTTPS 端點。
  • 必須由相同 Webhook 處理的多個主題。
  • App Engine 標準及 Cloud Functions 訂閱者。
  • 無法設定 Google Cloud Platform 依附元件 (例如憑證及用戶端程式庫) 的環境。

下表對提取與推送傳送進行了比較:

  提取 推送
端點 在網際網路上具有授權憑證的任何裝置都能夠呼叫 Cloud Pub/Sub API。 可在公開網路上存取的含非自行簽署之憑證的 HTTPS 伺服器。 接收端點可能會從 Cloud Pub/Sub 訂閱項目分離,以使來自多個訂閱項目的訊息可被傳送至單一端點。
負載平衡 多個訂閱者可對同一個「共用」訂閱項目進行提取呼叫。每個訂閱者都將接收訊息的子集。 推送端點可以是負載平衡器。
設定 不需要設定。 與訂閱者相同的專案中的 App Engine 應用程式不需要設定。
針對其他所有端點,Google Cloud Platform 主控台中都需要推送端點的設定 (與驗證)。端點必須能夠透過 DNS 名稱抵達,且已安裝 SSL 憑證。
流量控制 訂閱者用戶端可控制傳送速率。訂閱者可以動態修改確認期限,允許訊息處理時間達到任意長度。 Cloud Pub/Sub 伺服器會自動實作流量控制。不需要在用戶端處理訊息流量,但可以指示用戶端無法透過傳回 HTTP 錯誤來處理目前訊息負載。
效率與總處理量 允許批次傳送及確認,並且可以大量平行耗用,以低 CPU 與頻寬達到高總處理量。如果使用增強型輪詢來將訊息傳送時間減到最短,則可能效率不彰。 每個要求傳送一個訊息,並限制尚未解決訊息的數目上限。

訂閱的生命週期

根據預設,訂閱沒有活動 31 天後就會過期 (例如沒有有效連線、提取要求或成功推送)。如果 Cloud Pub/Sub 偵測到訂閱者活動,訂閱刪除時鐘就會重新啟動。您可利用訂閱過期政策 (Beta 版) 設定無活動時間,或是讓訂閱持續存在,不受活動影響。您也可以手動刪除訂閱。

請注意,雖然您可利用已刪除訂閱的相同名稱建立新訂閱,但新舊訂閱之間並無關聯。即使已刪除訂閱具有大量未確認訊息,同名的新訂閱在建立時也不會有待處理作業 (沒有等待提交的訊息)。

如要進一步瞭解如何處理訂閱,請參閱設定訂閱項目一文。

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Cloud Pub/Sub