本文假設您已熟悉訂閱 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，在訂閱項目中啟用訊息排序，並依序確認訊息。 |