推送訂閱

本文件將概略介紹推播訂閱、工作流程和相關資源。

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

推播訂閱可盡量減少對 Pub/Sub 專屬用戶端程式庫和驗證機制的依附元件。這些功能也能搭配無伺服器和自動調整服務技術 (例如 Cloud Run 函式、Cloud Run 和 Google Kubernetes Engine) 使用。

事前準備

閱讀本文前，請先熟悉下列概念：

推送訂閱工作流程

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

下圖顯示訂閱者用戶端與推播訂閱之間的工作流程。

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

以下簡要說明參照圖 3 的工作流程：

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

推送訂閱項目的屬性

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

推送端點接收訊息的方式

當 Pub/Sub 將訊息傳送至推送端點時，您可以選擇傳送已包裝或未包裝的訊息。根據預設，系統會傳送已包裝的訊息。

  • 已包裝。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 個後，時間窗口會以線性方式增加，以免推播端點收到過多訊息。如果平均延遲時間超過 1 秒，或訂閱者回應的請求少於 99%，則時間窗口會縮短至 3,000 個未送達訊息的下限。

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

配額與限制

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

後續步驟