發布至 Pub/Sub 主題的最佳做法

在發布過程中，發布端用戶端會將訊息傳送至 Pub/Sub 主題。以下是將訊息發布至 Pub/Sub 的最佳做法。

本文假設您已熟悉將訊息發布至 Pub/Sub 主題的程序。

如果您是 Pub/Sub 新手，請參閱其中一份快速入門指南，瞭解如何使用控制台、gcloud CLI 或用戶端程式庫執行 Pub/Sub。

根據發布作業的回應採取行動

高階用戶端程式庫的發布呼叫完成後，會傳回包含作業結果的未來物件。為避免封鎖個別發布要求，請以非同步方式處理結果。請根據您的用途，決定處理失敗的最佳方式。例如：

  • 記錄錯誤，不執行其他動作 (如果您的用途不需要成功發布所有訊息)。
  • 如果發生可能為暫時性的失敗 (例如 Deadline exceeded 錯誤)，請重新嘗試發布。
  • 將訊息保存至檔案或儲存空間，以便稍後重試發布，特別是需要使用者介入的錯誤，例如 Not found 或 Permission denied。
  • 將錯誤傳播至上游服務，該服務會傳送您嘗試發布的訊息。

如果您認為 Pub/Sub 未如預期將訊息傳送給訂閱者，請確認您有追蹤發布結果，且發布作業成功。

如果發布成功，發布呼叫的結果會是已發布訊息的訊息 ID。

保留訊息 ID

為方便疑難排解，發布端和訂閱端應保留已發布訊息的訊息 ID。您可以儲存每則已發布訊息的 ID，或視需要啟用訊息 ID 記錄功能。保留訊息 ID 有助於排解重複訊息、重新傳送、資料遺失和其他常見問題。詳情請參閱「處理重複項目」。

請先附加訂閱項目或啟用主題保留功能，再開始發布

如果開始發布至未附加訂閱者的主題，系統不會保留訊息。這些訊息無法傳送至後續附加的訂閱項目。因此，開始發布訊息前，請執行下列任一操作：

設定批次訊息傳遞功能

在 Pub/Sub 中，批次訊息是指將多則訊息合併為一批，並透過單一發布要求發布。如果您使用用戶端程式庫發布訊息，系統預設會啟用批次處理功能。批次處理 (或分組) 訊息有助於發布者提高效率，並以更高的處理量傳送訊息。批次處理可降低發布資料的費用。不過，批次處理也會造成個別訊息的延遲，因為發布者會等待批次填滿後再發布。

Pub/Sub 的延遲時間可分為兩種類型：

  • 端對端延遲時間是指訊息從發布端發布，到傳送至對應訂閱端處理所需的時間。

  • 發布延遲時間是指發布訊息所需的時間。

使用批次處理時，增加這兩種延遲時間是提高效率和處理量的折衷做法。

您可以根據訊息要求大小、訊息數量和時間，在用戶端程式庫中批次處理訊息。設定批次時，您可以根據用途，在成本、處理量和延遲時間之間取得適當平衡。

批次訊息變數的預設值和變數名稱可能因用戶端程式庫而異。您可以在用戶端程式庫中指定一或三個值。只要符合批次訊息變數的任一值，用戶端程式庫就會發布下一批訊息。

如要為發布端用戶端設定批次訊息傳遞功能，請參閱「在發布要求中批次處理訊息」。

設定流量控制，因應訊息量短暫激增

如果發布端用戶端必須處理大量訊息，發布要求可能會開始在記憶體中累積，直到訊息無法發布並出現 Deadline exceeded 錯誤為止。

如要解決發布訊息時暫時出現的高峰，您可以在發布者設定中使用流量控制。發布端流量控管機制可避免發布端用戶端資源因未處理的要求過多而超載。如果發布端用戶端在記憶體、CPU 或執行緒方面受到限制，就會產生大量 Deadline exceeded 錯誤。

如要在用戶端程式庫中設定流量控制，請為待處理訊息數量上限和待處理訊息位元組數上限變數設定適當的值。這些值可平衡訊息處理量和系統容量。

如要確認用戶端程式庫是否支援發布者流量控制，以及如何設定，請參閱「流量控制」。

瞭解網路頻寬和延遲時間

發布者處理量會受到網路頻寬和傳送的要求數量限制。如果頻寬良好，但網路延遲時間過長，請勿傳送大量小型要求，以免系統不堪負荷。發布商端流量控制功能可協助解決用戶端網路問題。

發布者處理量也受限於 CPU 和記憶體。可用的機器核心越多，就能設定更高的執行緒數量，提高發布處理量。如要進一步瞭解如何盡可能提高串流效能，請參閱「測試 Cloud Pub/Sub 用戶端，盡可能提高串流效能」。

調整失敗發布作業的重試要求變數

發布者用戶端發布訊息時，您可能會看到發布失敗。這類失敗通常是由用戶端瓶頸造成，例如服務 CPU 不足、執行緒健康狀態不佳或網路壅塞。publisher retry policy 會決定訊息傳送失敗時的行為。重試政策會定義 Pub/Sub 嘗試傳送訊息的次數，以及每次嘗試之間的間隔時間。

舉例來說，在 Pub/Sub 的 Java 用戶端程式庫中，發布端用戶端包含下列值：

  • initialRetryDelay。發布者在重試發布作業前，等待的初始延遲時間。預設值為 100 milliseconds。

  • retryDelayMultiplier。用於計算重試延遲時間的乘法係數。預設值為 4。也就是說，第二次重試的延遲時間最多為 100 milliseconds * 4 = 400 milliseconds，第三次重試則最多為 400 milliseconds * 4 = 1600 milliseconds。

  • maxRetryDelay：發布者重試發布作業前的最長等待時間。預設值為 60 seconds。

  • initialRpcTimeout。發布者等待 RPC 呼叫完成的初始逾時時間。預設值為 5 seconds。

  • rpcTimeoutMultiplier. 用於計算 RPC 逾時時間的乘法係數。預設值為 4.0。這表示第二次重試時，RPC 呼叫的逾時時間最多為 5 seconds * 4 = 20 seconds，第三次重試時則最多為 10 seconds * 4 = 40 seconds。

  • maxRpcTimeout. 發布者等待 RPC 呼叫完成的時間上限。預設值為 600 seconds。

  • totalTimeout。發布作業的總逾時時間。這包括等待 RPC 呼叫完成的時間，以及重試之間的等待時間。預設值為 600 seconds。

只有在發現預設重試設定不符合用途時，才需要調整指定的值。舉例來說，發布大量訊息時，您不需要增加 initialRetryDelay 和 maxRetryDelay 值。不過，在這種情況下，您可以調整流量控制和批次處理。如果您是透過不穩定的網際網路連線或頻寬受限的連線發布，可以嘗試調整 initialRpcTimeout、maxRpcTimeout 和 rpcTimeoutMultiplier 變數的值。如需建議值，請參閱「發布作業失敗，並顯示 DEADLINE_EXCEEDED」。

使用訊息儲存政策確保資料位置

Pub/Sub 的主題訊息儲存政策可確保發布至主題的訊息，一律不會保留在您指定的一組Google Cloud 區域之外，無論發布要求來自何處。

使用訊息儲存政策，指定 Pub/Sub 可將訊息資料儲存在磁碟上的 Google Cloud 區域清單。如果訊息發布至不在這份清單中的區域，系統會將要求轉送至最近的允許區域進行處理。這項政策可以設定在主題上，也可以設為專案、專案資料夾或整個組織的組織政策。設定組織政策後，個別主題政策只能以不違反組織政策的方式變更。

舉例來說，在歐洲營運的公司可能會使用訊息儲存政策，確保所有資料都儲存在歐盟地區，以遵守當地法律。

詳情請參閱「設定訊息儲存政策」。

發布有序訊息的最佳做法

如果使用訊息排序功能，請確認下列事項：

  • 使用位置端點。訊息順序會在發布端和區域內保留。換句話說，如果您將訊息發布至多個區域，只有同一區域內的訊息會按照一致的順序傳送。如果訊息都發布至同一個區域，但訂閱端分散在不同區域，則訂閱端會按照順序接收所有訊息。使用位置端點，將訊息發布至相同區域。

  • 設定繼續發布函式。當用戶端程式庫重試要求，且訊息含有排序鍵時，用戶端程式庫會重複重試要求，不受重試設定影響。如果發生無法重試的錯誤，用戶端程式庫就不會發布訊息，並停止發布其他具有相同排序鍵的訊息。準備好繼續使用發布失敗的排序金鑰發布時，請呼叫 resumePublish 方法。

最佳做法摘要

下表彙整了本文建議的最佳做法：

主題 工作
設定訊息保留功能 請先附加訂閱項目，再發布或啟用訊息保留功能。
在發布要求中批次處理訊息 批次或群組訊息，提高發布者的效率，並以更高的處理量傳送訊息。
流量控制 在發布者設定中設定流量控制，以處理暫時性的流量高峰。
測試 Pub/Sub 用戶端，盡可能提高串流效能 增加可用的機器核心和網路頻寬，提高發布者處理量。
重試要求 只有在發現預設設定不符合您的用途時，才需要調整發布者重試政策的指定值。
設定訊息儲存政策 使用訊息儲存空間政策，僅在特定位置將訊息資料儲存在磁碟上。
在發布作業中使用排序鍵時，請使用位置端點 使用排序訊息時，請使用位置端點，並設定發布失敗時的繼續發布函式。

後續步驟