Push-Abos

Dieses Dokument bietet einen Überblick über ein Push-Abo, dessen Workflow und die zugehörigen Attribute.

Bei der Push-Zustellung initiiert Pub/Sub Anfragen an Ihre Abonnentenanwendung, um Nachrichten zuzustellen. Nachrichten werden an einen öffentlich adressierbaren Server oder einen Webhook gesendet, z. B. eine HTTPS-POST-Anfrage.

Mit Push-Abos lassen sich Abhängigkeiten von Pub/Sub-spezifischen Clientbibliotheken und Authentifizierungsmechanismen minimieren. Sie funktionieren auch gut mit serverlosen und Autoscaling-Diensttechnologien wie Cloud Functions, Cloud Run und Google Kubernetes Engine.

Hinweise

Bevor Sie dieses Dokument lesen, machen Sie sich mit folgenden Themen vertraut:

• Funktionsweise von Pub/Sub und die verschiedenen Pub/Sub-Begriffe

• Die verschiedenen Arten von Abos, die Pub/Sub unterstützt und warum Sie ein Push-Abo verwenden sollten.

Workflow für Push-Abos

In einem Push-Abo initiiert ein Pub/Sub-Server eine Anfrage an Ihren Abonnentenclient, um Nachrichten zu senden.

Die folgende Abbildung zeigt den Workflow zwischen einem Abonnentenclient und einem Push-Abo.

Abbildung 3: Workflow für ein Push-Abo

Hier ist eine kurze Beschreibung des Workflows, der auf Abbildung 3 verweist:

1. Der Pub/Sub-Server sendet jede Nachricht als HTTPS-Anfrage an den Abonnentenclient an einem vorkonfigurierten Endpunkt. Diese Anfrage wird als PushRequest im Bild angezeigt.
2. Der Endpunkt bestätigt die Nachricht, indem er einen HTTP-Erfolgsstatuscode zurückgibt. Wenn die Antwort nicht erfolgreich war, muss Pub/Sub die Nachrichten noch einmal senden. Diese Antwort wird im Bild als PushResponse angezeigt.
3. Pub/Sub passt die Rate von Push-Anfragen basierend auf der Rate, mit der erfolgreiche Erfolgsantworten empfangen werden, dynamisch an.

Eigenschaften eines Push-Abos

Die Attribute, die Sie für ein Push-Abo konfigurieren, bestimmen, wie Nachrichten in Ihr Abo geschrieben werden. Weitere Informationen findest du unter Abo-Properties.

So empfangen Push-Endpunkte Nachrichten

Wenn Pub/Sub eine Nachricht an einen Push-Endpunkt sendet, können Sie diese ein- oder unverpackt senden. Nachrichten werden standardmäßig umschlossen.

• Eingewickelt Pub/Sub sendet die Nachricht im JSON-Text einer POST-Anfrage.
• Nicht verpackt: Pub/Sub sendet die Rohnachrichtendaten direkt als HTTP-Text.

Das folgende Beispiel zeigt den umschlossenen Text einer JSON-POST-Anfrage an einen Push-Endpunkt, der den String Hello there im Feld message.data enthält:

Der Text einer POST-Anfrage ist ein JSON-Objekt. Die Nachrichtendaten befinden sich im Feld message.data und sind base64-codiert.

  {
      "message": {
          "attributes": {
              "key": "value"
          },
          "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"
  }

Wenn Sie Nachrichten von Push-Abos erhalten möchten, verwenden Sie einen Webhook und verarbeiten Sie die POST-Anfragen, die Pub/Sub an den Push-Endpunkt sendet. Weitere Informationen zum Verarbeiten dieser POST-Anfragen in App Engine finden Sie unter Pub/Sub-Nachrichten schreiben und beantworten.

Wenn Sie eine Push-Anfrage erhalten haben, geben Sie einen HTTP-Statuscode zurück. Um die Nachricht zu bestätigen, geben Sie einen der folgenden Statuscodes zurück:

• 102
• 200
• 201
• 202
• 204

Wenn Sie eine negative Bestätigung für die Nachricht senden möchten, geben Sie einen anderen Statuscode zurück. Wenn Sie eine negative Bestätigung oder die Bestätigungsfrist senden, sendet Pub/Sub die Nachricht noch einmal. Sie können die Bestätigungsfrist einzelner Nachrichten, die Sie über Push-Abos erhalten, nicht ändern.

Authentifizierung für Push-Abos

Wenn für ein Push-Abo die Authentifizierung verwendet wird, signiert der Pub/Sub-Dienst ein JWT und sendet das JWT im Autorisierungsheader der Push-Anfrage.

Weitere Informationen zum Einrichten der Authentifizierung finden Sie unter Push-Anfragen authentifizieren.

Zustellung von Nachrichten stoppen und fortsetzen

Sie können das Senden von Anfragen an den Push-Endpunkt in Pub/Sub vorübergehend anhalten. Ändern Sie dazu das Abo in Pull. Es kann einige Minuten dauern, bis die Umstellung wirksam wird.

Zum Fortsetzen der Push-Zustellung wählen Sie für die URL wieder einen gültigen Endpunkt aus. Löschen Sie das Abo, wenn Sie die Zustellung dauerhaft stoppen möchten.

Push-Backoff

Wenn ein Push-Abonnent zu viele negative Bestätigungen sendet, kann Pub/Sub Nachrichten mithilfe eines Push-Backoffs ausliefern. Wenn Pub/Sub einen Push-Backoff verwendet, werden damit für einen festgelegten Zeitraum keine Nachrichten mehr gesendet. Diese Zeitspanne kann zwischen 100 Millisekunden und 60 Sekunden liegen. Nach Ablauf der Zeit beginnt die Pub/Sub-Zustellung wieder.

Hinweis :Diese Funktion ist unabhängig von den Richtlinien für Abo-Wiederholungen. Mit diesen beiden Funktionen können Sie den Nachrichtenfluss besser steuern. In diesem Fall ist die Gesamtverzögerung der maximale Gesamtwert des Pushoff-Werts und des Werts der Wiederholungsrichtlinie. Wenn Probleme mit der Nachrichtenzustellung auftreten, prüfen Sie noch einmal, wie die Wiederholungsrichtlinie mit dem Push-Backoff interagiert.

Push-Backoffs verwendet einen exponentiellen Backoff-Algorithmus, um die Verzögerung zu ermitteln, die Pub/Sub zwischen dem Senden von Nachrichten verwendet. Dieser Zeitraum wird anhand der Anzahl der negativen Bestätigungen berechnet, die Push-Abonnenten senden.

Wenn ein Push-Abonnent beispielsweise fünf Nachrichten pro Sekunde empfängt und eine negative Bestätigung pro Sekunde sendet, stellt Pub/Sub Nachrichten etwa alle 500 Millisekunden zu. Wenn der Push-Abonnent fünf negative Bestätigungsnachrichten pro Sekunde sendet, sendet Pub/Sub Nachrichten alle 30 bis 60 Sekunden.

Beachten Sie Folgendes:

• Pushback kann nicht aktiviert oder deaktiviert werden. Sie können auch nicht die Werte ändern, die zur Berechnung der Verzögerung verwendet werden.
• Pushback-Trigger für die folgenden Aktionen ausführen:
  • Wenn eine negative Bestätigung eingegangen ist
  • Wenn die Bestätigungsfrist einer Nachricht abläuft.
• Push-Backoffs gelten für alle Nachrichten in einem Abo (weltweit).

Zustellungsrate

Pub/Sub passt die Anzahl der gleichzeitigen Push-Anfragen mit einem Slow-Start-Algorithmus an. Die maximal zulässige Anzahl gleichzeitiger Push-Anfragen ist das Push-Fenster. Das Push-Fenster verlängert sich bei jeder erfolgreichen Auslieferung und verringert sich bei Fehlern. Das System beginnt mit einer kleinen einstelligen Fenstergröße.

Wenn ein Abonnent Nachrichten erkennt, erhöht sich das Fenster exponentiell. Bei Abos, bei denen Abonnenten mehr als 99% der Nachrichten bestätigen und eine Latenz von weniger als einer Sekunde bei der Push-Anfrage auftritt, sollte das Push-Fenster so stark erweitert werden, dass es mit dem Veröffentlichungsdurchsatz Schritt hält.

Die Latenz der Push-Anfrage umfasst Folgendes:

• Die Umlauf-Netzwerklatenz zwischen Pub/Sub-Servern und dem Push-Endpunkt

• Die Verarbeitungszeit des Abonnenten

Nach 3.000 ausstehenden Nachrichten pro Region wird das Fenster linear erhöht,um zu verhindern, dass der Push-Endpunkt zu viele Nachrichten empfängt. Wenn die durchschnittliche Latenz eine Sekunde überschreitet oder der Abonnent weniger als 99% der Anfragen bestätigt, verringert sich das Fenster auf das untere Limit von 3.000 ausstehenden Nachrichten.

Weitere Informationen zu den Messwerten, die Sie für das Monitoring der Push-Zustellung verwenden können, finden Sie unter Push-Abos beobachten.

Kontingente und Limits

Push-Abos unterliegen einer Reihe von Kontingenten und Ressourcenlimits.

Nächste Schritte

• Erstellen Sie ein Push-Abo für Ihr Thema.

• Abos mit der gcloud CLI erstellen oder ändern

• ein Abo mit REST APIs erstellen oder ändern

• ein Abo mit RPC APIs erstellen oder ändern