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

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

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

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

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

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

  • 記錄錯誤，然後不採取任何行動 (如果您的用途不需要成功發布所有訊息)。
  • 如果發生 Deadline exceeded 錯誤等暫時性失敗，請重試發布。
  • 將訊息保留在檔案或儲存空間中，以便稍後重試發布，尤其是在發生需要使用者介入的錯誤時，例如 Not found 或 Permission denied。
  • 將錯誤傳播至上游服務，該服務會傳送您嘗試發布的訊息。

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

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

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

設定批次訊息

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

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

  • 端對端延遲是指發布者發布訊息，並將訊息傳送至對應訂閱者進行處理所花費的時間。

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

使用批次處理時，增加這兩種延遲時間，可換取效率和輸送量提升。

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

批次訊息變數的預設值和變數名稱可能因用戶端程式庫而異。您可以在用戶端程式庫中指定一或全部三個值。如果批次訊息傳遞變數的任何一個值達到上限，用戶端程式庫就會發布下一批訊息。

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

設定流量控管，因應暫時的訊息量暴增情況

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

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

如要在用戶端程式庫中設定流量控管，請為「maximum outstanding messages」(未處理訊息數量上限) 和「maximum outstanding message bytes」(未處理訊息位元組數量上限) 變數設定適當的值。這些值可平衡訊息輸送量和系統容量。

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

瞭解網路頻寬和延遲

發布商的輸送量會受到網路頻寬和傳送要求數量的限制。如果頻寬良好，但網路延遲時間較長，請勿以大量小型要求塞爆系統。發布商端流量控制有助於解決用戶端網路問題。

發布者輸送量也會受到 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 區域之外，與發布要求來源無關。

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

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

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

發布時使用排序訊息的最佳做法

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

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

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

最佳做法摘要

下表總結了本文建議的最佳做法：

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

後續步驟