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