本文件假設您已熟悉訂閱 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 會在訊息確認後，從訂閱項目中捨棄該訊息。如果您在傳送確認訊息前未處理訊息，且處理作業失敗，服務就不會重新傳送訊息。例外狀況是，如果您已設定保留已確認訊息或主題保留功能，並執行搜尋作業。
如果您有高延遲的訂閱者，可能需要為流量控制和租用管理設定自訂值。
針對暫時性流量尖峰設定訂閱者流量控管
訂閱者端的流量控制可避免訂閱者因流量激增而超載。這可讓自動調整資源的機制有時間回應負載增加的情況，或是將負載的處理時間分散到更長的時間。前者可節省延遲時間，後者則可節省成本。
如要設定資料流控制，您必須為 maximum outstanding messages 和 total outstanding message bytes 設定適當的值。這些流程控制變數的預設值和變數名稱，可能因用戶端程式庫而異。
「未處理訊息數上限」定義了未收到確認或負面確認的訊息，可傳送至用戶端的訊息數量上限。
「總未完成的訊息位元組數」定義了傳送至用戶端的訊息總大小上限，而 Pub/Sub 尚未收到確認或負面確認。
如果超過上述任一選項的上限，訂閱者用戶端就不會再擷取郵件。這項行為會持續進行，直到已擷取的訊息獲得確認或否定確認為止。這樣一來，您就能在運行更多訂閱者時，以成本換取吞吐量。
訂閱中排序訊息的最佳做法
如果您使用訊息排序功能，請確認下列事項：
選擇「StreamingPull」或「Pull」訂閱。對於推送訂閱，Pub/Sub 每次只支援每個排序鍵的一個未完成訊息。在這種情況下，傳送並行推播要求就像是傳送多個批次訊息，以便同時提取訂閱者。因此，如果主題經常發布多則訊息，且使用相同的排序鍵，或延遲時間非常重要，則不建議使用推播訂閱。
在訂閱項目中啟用訊息排序功能。在發布端，如果您傳送的訊息含有排序鍵且位於同一個區域，您可以設定訂閱者按照順序接收這些訊息。在訂閱者端，請只針對要接收有序訊息的訂閱項目啟用訊息排序資源。視資源狀態而定，附加至主題的每個訂閱項目可決定是否需要有序傳送，且不會互相影響。
依序確認訊息。使用排序傳送功能時，系統會依照排序鍵處理先前訊息的確認回應，然後才處理後續訊息的確認回應。舉例來說，如果您有使用相同排序鍵的 1、2 和 3 號訊息，且您收到所有訊息，但只確認 3 號訊息，服務會在 1 和 2 號訊息也已確認後，才會將 3 號訊息視為已確認。如果未收到訊息 1 和 2 的確認回應，系統會重新傳送訊息 1、2 和 3。
最佳做法摘要
下表總結了本文件中建議的最佳做法：
| 主題 | 工作 |
|---|---|
| 選擇訂閱類型 | 選擇符合業務需求的訂閱類型。如果您的訂閱方案支援高階用戶端程式庫，請一併使用這類程式庫。 |
| 重播已確認的訊息 | 請先處理訊息，再確認訊息。或者，您也可以設定搜尋作業，以免遺失已確認的訊息。 |
| 流量控制 | 在訂閱者設定中設定流程控制，確保在自動調整資源配置功能啟用或時間過後，訂閱者不會過載。 |
| 排序訊息 | 使用有序訊息時，請選擇「StreamingPull」或「Pull」，在訂閱中啟用訊息排序功能，並依序確認訊息。 |