發送訂閱

本文將概略介紹推送訂閱項目、工作流程和相關聯的屬性。

在推送傳送中，Pub/Sub 會向您的訂閱者應用程式發出傳送訊息的要求。訊息會傳送至可公開定址的伺服器或 Webhook，例如 HTTPS POST 要求。

推送訂閱可盡量減少對 Pub/Sub 專屬用戶端程式庫和驗證機制的依附元件。這些服務也適用於無伺服器和自動調整服務技術，例如 Cloud Run functions、Cloud Run 和 Google Kubernetes Engine。

事前準備

閱讀本文前，請務必先熟悉下列項目：

推送訂閱項目工作流程

在推送訂閱項目中，Pub/Sub 伺服器會向訂閱端用戶端發出要求，傳送訊息。

下圖顯示訂閱端用戶端與推送訂閱項目之間的工作流程。

推送訂閱項目的訊息流程
圖 3. 推送訂閱項目的工作流程

以下簡要說明圖 3 所示的工作流程：

  1. Pub/Sub 伺服器會將每個訊息做為 HTTPS 要求傳送至位於預先設定端點的訂閱端用戶端。圖片中的 PushRequest 代表這項要求。
  2. 端點會傳回 HTTP 成功狀態碼來確認訊息。如果回應不是成功，表示 Pub/Sub 必須重新傳送訊息。圖片中的 PushResponse 即為這項回應。
  3. Pub/Sub 會根據收到成功回應的速率，動態調整推送要求的速率。

推送訂閱項目的屬性

您為推送訂閱項目設定的屬性，會決定如何將訊息寫入訂閱項目。詳情請參閱「訂閱屬性」。

推送端點如何接收訊息

Pub/Sub 將訊息傳送到推送端點時，您可以選擇傳送包裝或未包裝的訊息。根據預設，系統會以換行方式傳送訊息。

  • Wrapped。Pub/Sub 會在 POST 要求的 JSON 內文中傳送訊息。
  • Unwrapped. Pub/Sub 會直接將原始訊息資料做為 HTTP 主體傳送。

下列範例顯示傳送至推送端點的 JSON POST 要求包裝主體，其中包含 message.data 欄位中的字串 Hello there

POST 要求的內文是 JSON 物件。訊息資料位於 message.data 欄位，並採用 base64 編碼。

要求範例 (使用最小值)

  {
      "message": {
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
  }

要求範例 (使用最大值)

請注意，這個範例顯示的是目前的最大值，可能會隨時間變更。此外，屬性對應表可包含各種值。

  {
      "deliveryAttempt": 5,
      "message": {
          "attributes": {
              "key": "value"
          },
          "data": "SGVsbG8gQ2xvdWQgUHViL1N1YiEgSGVyZSBpcyBteSBtZXNzYWdlIQ==",
          "messageId": "2070443601311540",
          "message_id": "2070443601311540",
          "orderingKey": "key",
          "publishTime": "2021-02-26T19:13:55.749Z",
          "publish_time": "2021-02-26T19:13:55.749Z"
      },
    "subscription": "projects/myproject/subscriptions/mysubscription"
}

如要接收推送訂閱項目的訊息，請使用 Webhook 並處理 Pub/Sub 傳送至推送端點的 POST 要求。如要進一步瞭解如何在 App Engine 中處理這些 POST 要求，請參閱「編寫及回應 Pub/Sub 訊息」。

收到推送要求後，請傳回 HTTP 狀態碼。如要確認收到訊息，請傳回下列其中一個狀態碼：

  • 102
  • 200
  • 201
  • 202
  • 204

如要傳送訊息的否定確認，請傳回任何其他狀態碼。如果您傳送負面確認，或確認期限到期，Pub/Sub 會重新傳送訊息。您無法修改透過推送訂閱項目收到的個別訊息確認期限。

推送訂閱的驗證操作

如果推送訂閱項目使用驗證，Pub/Sub 服務會簽署 JWT，並在推送要求的授權標頭中傳送 JWT。

如要進一步瞭解如何設定驗證，請參閱「驗證推送要求」。

停止及繼續傳送訊息

如要讓 Pub/Sub 暫時停止傳送請求至推送端點，請將訂閱項目變更為提取模式。 變更可能需要幾分鐘才會生效。

如要繼續傳遞推送訂閱項目，請再次將網址設定為有效端點。如要永久停止傳遞訂閱項目，則需刪除訂閱項目。

停止推送

如果推送訂閱者傳送過多負面確認訊息，Pub/Sub 可能會開始使用推送退避傳送訊息。Pub/Sub 使用推送退避時，會停止傳送訊息一段預先決定的時間。這個時間範圍可以介於 100 毫秒到 60 秒之間。 時間到期後，Pub/Sub 會再次開始傳送訊息。

推送輪詢會使用「指數輪詢」演算法，判斷 Pub/Sub 傳送訊息之間的延遲時間。這段時間是根據推送訂閱者傳送的否定確認數量計算而得。

舉例來說，如果推送訂閱者每秒收到五則訊息，並每秒傳送一則否定確認訊息，Pub/Sub 大約每 500 毫秒就會傳送訊息。或者，如果推送訂閱者每秒傳送五個否定確認，Pub/Sub 會每 30 到 60 秒傳送一次訊息。

請注意下列有關推送退避的注意事項：

  • 您無法開啟或關閉延遲推送功能，也無法修改用於計算延遲時間的值。
  • 在下列動作中觸發延遲：
    • 收到否定確認時。
    • 訊息的確認期限到期。
  • 推送輪詢適用於訂閱項目中的所有訊息 (全域)。

放送率

Pub/Sub 會使用慢速啟動演算法調整並行推送要求數量。並行推送要求數量上限為推送視窗。如果傳送成功，推送視窗就會增加；如果傳送失敗，推送視窗就會縮短。系統會先採用個位數的較小視窗大小。

訂閱者確認訊息時，視窗會以指數方式增加。如果訂閱項目中，訂閱端確認的訊息超過 99%，且推送要求的平均延遲時間少於一秒，推送視窗應擴展到足以跟上任何發布端處理量。

推送要求延遲時間包括：

每個區域有 3,000 則未處理的訊息後，視窗會線性增加，避免推送端點收到過多訊息。如果平均延遲時間超過一秒，或訂閱者確認的要求少於 99%，視窗就會縮減至 3,000 則未處理訊息的下限。

如要進一步瞭解可用於監控推送傳送作業的指標，請參閱「監控推送訂閱」。

配額與限制

推送訂閱項目具有配額和資源方面的限制。

後續步驟