訂閱者總覽

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

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

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

至少一次的傳送

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

  • 依據預設,無法在最長保留時間 7 天內傳送的訊息會遭到刪除,且無法再存取。這通常會在訂閱者跟不上訊息流程時發生。請注意,您可設定訊息保留時間 (範圍為 10 分鐘至 7 天)。如需進一步瞭解訊息保留設定,請參閱重播及捨棄訊息一文。
  • 一般將不會傳送在建立特定訂閱項目之前發佈的訊息。 因此,無法擷取發佈至沒有訂閱項目之主題的訊息。

將訊息傳送至訂閱者後,訂閱者必須確認或忽略訊息。當訊息被送出至待傳送狀態,而訂閱者尚未確認之前,訊息會被視為尚未解決。Cloud Pub/Sub 將會重複嘗試傳送尚未確認或非尚未解決的所有訊息。訂閱者具有可設定的受限制時間量,或稱 ackDeadline,可用來確認訊息。超過期限之後,尚未解決的訊息會變為未確認。

通常,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