本文假設您已熟悉訂閱 Pub/Sub 主題,以及在訂閱端用戶端接收訊息的程序。
如果您是 Pub/Sub 新手,請參閱其中一篇快速入門指南,瞭解如何使用控制台、Google Cloud CLI 或用戶端程式庫執行 Pub/Sub。
選擇合適的訂閱方案
Pub/Sub 提供「推送」和「提取」訂閱等標準訂閱項目。除了標準訂閱項目,Pub/Sub 也提供匯出訂閱項目,可讓您直接將訊息儲存到Trusted Cloud by S3NS 資源,不需要 Dataflow 做為中介服務。舉例來說,BigQuery 訂閱項目會將訊息儲存在 BigQuery 資料表中。
建議在下列情境中使用推送訂閱:
訂閱端應用程式不得包含任何程式碼,將用戶端程式庫匯入為依附元件。
訂閱端用戶端無法發出任何外送要求。
您想使用同一個執行個體處理來自不同主題和訂閱項目的訊息,但訂閱者用戶端不知道訂閱項目清單。
一般情況下,建議使用高階用戶端程式庫。如果您改用一元提取,請勿將 returnImmediately
設為 true
。設為 true
會對提取作業效能造成負面影響。
returnImmediately
欄位現已淘汰。
如要比較所有訂閱類型,並選擇最符合業務需求的類型,請參閱 Pub/Sub 訂閱方案比較表。
如要瞭解匯出訂閱的優點,請參閱何時該使用匯出訂閱。
先處理訊息,再確認訊息
根據預設,Pub/Sub 會在訊息確認後,從訂閱項目捨棄該訊息。如果您未先處理訊息就傳送確認訊息,且處理失敗,服務不會重新傳送訊息。但如果您已設定保留已確認的訊息或主題保留,並執行搜尋作業,則不受此限。
如果訂閱者的延遲時間較長,您可能需要為流量控管和租約管理設定自訂值。
針對暫時性流量尖峰設定訂閱者流量控管
訂閱端流量控制功能可防止訂閱者因流量暴增而過載。這可讓自動調度機制有時間因應負載增加,或將負載處理作業分散到較長的時間內。前者可節省延遲時間,後者則可節省費用。
如要設定流量控管,請為 maximum outstanding messages
和 total outstanding message bytes
設定適當的值。這些流程控制變數的預設值和變數名稱可能因用戶端程式庫而異。
「未處理訊息數上限」定義傳送至用戶端的訊息數量上限,Pub/Sub 尚未收到這些訊息的確認或負面確認。
未處理的訊息位元組總數:傳送至用戶端但 Pub/Sub 尚未收到確認或負面確認的訊息總大小上限。
如果超過其中一個選項的限制,訂閱端就不會再提取更多訊息。這種情況會持續到已提取的訊息獲得確認或負面確認為止。這樣一來,您就能在輸送量與執行更多訂閱者相關的成本之間取得平衡。
處理重複傳送的訊息
根據預設,Pub/Sub 會為訂閱者提供至少一次的訊息傳送。也就是說,即使訊息已確認,仍可能多次傳送。下列各節將討論如何處理常見的重新傳送情境。
持續重新傳送大量郵件
如果經常發生大量訊息重新傳送的情況,表示訂閱者負載過重,或是在期限到期前未確認訊息。
如果您使用提取訂閱,可能需要設定自訂值,以調整流量控制值,或使用租約管理增加租約延長期限。
如果您使用推送訂閱,可能需要增加確認期限設定。你也可以遵循維持良好訂閱狀態的最佳做法。
偶爾會重新傳送訊息
如果在確認期限到期前或在幾秒內確認訊息後,看到訊息重新傳送,這是 Pub/Sub 的正常行為。您不應經常看到這些重新傳送尖峰,但重新傳送發生時,很可能同時發生在多則訊息上。您的系統必須能容許這些偶爾出現的重複項目。
重複重新傳送幾則訊息
如果發現少量郵件重複傳送多次,請先確認您是否已確認這些郵件。如果不是,請找出訂閱者未正確處理訊息的原因。您可能需要設定無效信件主題,避免系統進一步重新傳送訊息。如果您確認訊息,Pub/Sub 可能仍會正常運作。雖然機率極低,但如果發生內部網路或硬體中斷情形,仍有可能重複傳送少量訊息。在這些情況下,服務會嘗試自我修復,但補救措施可能需要幾分鐘才會生效。
您的系統必須能容許重新傳送。為降低這類情況發生的機率,請務必盡快處理及確認訊息。
如果應用程式無法容忍任何重複項目,可以啟用「只傳送一次」。請注意,這項功能僅適用於提取訂閱,且會導致發布至訂閱的延遲時間變長。啟用這項功能前,請評估較高的延遲是否符合您的用途。
訂閱時依序傳送訊息的最佳做法
如果使用訊息排序功能,請確認下列事項:
選擇 StreamingPull 或 Pull 訂閱項目。如果是推送訂閱,Pub/Sub 一次只支援每個排序鍵的一則待處理訊息。在這種情況下傳送並行推送要求,就類似於傳送多批訊息給相同排序鍵,同時提取訂閱者。因此,如果主題經常發布含有相同排序鍵的多則訊息,或對延遲時間極為敏感,就不建議使用推送訂閱。
在訂閱項目中啟用訊息排序功能。在發布端,如果您傳送的訊息含有排序鍵,且位於相同區域,您可以設定訂閱端依序接收這些訊息。在訂閱端,只為要接收排序訊息的訂閱項目啟用訊息排序屬性。視屬性狀態而定,附加至主題的每個訂閱項目可以決定是否需要依序傳送,不會相互影響。
依序確認訊息。使用依序傳送功能時,系統會先依排序鍵處理較早訊息的確認,再處理較晚訊息的確認。舉例來說,如果您有排序鍵相同的訊息 1、2 和 3,而且您收到所有訊息,但只確認訊息 3,服務會等到訊息 1 和 2 也確認後,才會將訊息 3 視為已確認。如果系統從未收到訊息 1 和 2 的確認,則會重新傳送訊息 1、2 和 3。
最佳做法摘要
下表總結了本文建議的最佳做法:
主題 | 工作 |
---|---|
選擇訂閱類型 | 根據業務需求選擇合適的訂閱類型。如果訂閱方案支援,也請使用高階用戶端程式庫。 |
重新傳送已確認的訊息 | 先處理訊息,再確認訊息。或者,設定搜尋作業,以免遺失已確認的訊息。 |
流量控制 | 在訂閱者設定中設定流量控管,確保訂閱者不會過載,直到自動調度資源啟動或時間經過為止。 |
排序訊息 | 使用排序訊息時,請選擇 StreamingPull 或 Pull,在訂閱項目中啟用訊息排序,並依序確認訊息。 |