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

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

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

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

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

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

設定批次訊息

在 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 區域之外，不受發布要求來源的影響。

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

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

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

發布中排序訊息的最佳做法

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

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

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

最佳做法摘要

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

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

後續步驟