Dieses Dokument bietet einen Überblick über ein Push-Abo, seinen Workflow und die zugehörigen Properties.
Bei der Push-Lieferung initiiert Pub/Sub, wenn es Nachrichten zustellen soll, Anfragen bei Ihrer Abonnentenanwendung. Nachrichten werden an einen öffentlich adressierbaren Server oder einen Webhook gesendet, z. B. über eine HTTPS-POST-Anfrage.
Push-Abos minimieren die Abhängigkeiten von Pub/Sub-spezifischen Clientbibliotheken und Authentifizierungsmechanismen. Sie eignen sich auch gut für serverlose und autoscalingfähige Diensttechnologien wie Cloud Run-Funktionen, Cloud Run und Google Kubernetes Engine.
Hinweise
Bevor Sie dieses Dokument lesen, sollten Sie mit Folgendem vertraut sein:
Funktionsweise von Pub/Sub und die verschiedenen Pub/Sub-Begriffe
Die verschiedenen Abotypen, die Pub/Sub unterstützt, und warum Sie ein Push-Abo verwenden sollten.
Workflow für Push-Abos
Bei einem Push-Abo sendet ein Pub/Sub-Server eine Anfrage an Ihren Abonnentenclient, um Nachrichten zuzustellen.
Das folgende Bild zeigt den Workflow zwischen einem Abonnentenclient und einem Push-Abo.
Hier eine kurze Beschreibung des Workflows, auf den Abbildung 3 verweist:
- Der Pub/Sub-Server sendet jede Nachricht als HTTPS-Anfrage an den Abonnentenclient an einem vorkonfigurierten Endpunkt. Diese Anfrage ist im Bild als
PushRequest
dargestellt. - Der Endpunkt bestätigt die Nachricht, indem er einen HTTP-Erfolgsstatuscode zurückgibt. Wenn in der Antwort angegeben wird, dass der Vorgang nicht erfolgreich war, muss Pub/Sub die Nachrichten noch einmal senden. Diese Antwort wird im Bild als
PushResponse
angezeigt. - Pub/Sub passt die Rate von Push-Anfragen anhand der Rate, mit der Erfolgsantworten empfangen werden, dynamisch an.
Eigenschaften eines Push-Abos
Die Eigenschaften, die Sie für ein Push-Abo konfigurieren, bestimmen, wie Sie Nachrichten an Ihr Abo schreiben. Weitere Informationen finden Sie unter Abo-Attribute.
So erhalten Push-Endpunkte Nachrichten
Wenn Pub/Sub eine Nachricht an einen Push-Endpunkt sendet, können Sie festlegen, ob sie gewickelt oder entwickelt gesendet werden soll. Standardmäßig werden Nachrichten umgebrochen gesendet.
- Umschlossen. Pub/Sub sendet die Nachricht im JSON-Text einer
POST
-Anfrage. - Unverpackt. Pub/Sub sendet die Rohnachrichtendaten direkt als HTTP-Hauptteil.
Die folgenden Beispiele zeigen einen eingekapselten 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.
Beispiel für eine Anfrage mit den Mindestwerten
{ "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" }
Beispiel für eine Anfrage mit den maximalen Werten
In diesem Beispiel sind die aktuellen Maximalwerte zu sehen, die sich im Laufe der Zeit ändern können. Außerdem kann die Attributzuordnung verschiedene Werte enthalten.
{ "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" }
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 senden oder die Bestätigungsfrist abläuft, sendet Pub/Sub die Nachricht noch einmal. Sie können die Bestätigungsfrist für einzelne Nachrichten, die Sie von Push-Abos erhalten, nicht ändern.
Authentifizierung für Push-Abonnements
Wenn für ein Push-Abo die Authentifizierung verwendet wird, signiert der Pub/Sub-Dienst ein JWT und sendet es 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, stellt Pub/Sub Nachrichten möglicherweise mit einem Push-Backoff zu. Wenn Pub/Sub einen Push-Backoff verwendet, werden keine Nachrichten mehr für eine festgelegte Zeit zugestellt. Dieser Zeitraum kann zwischen 100 Millisekunden und 60 Sekunden liegen. Nach Ablauf der Zeit beginnt Pub/Sub wieder mit der Zustellung von Nachrichten.
Beim Push-Backoff wird ein exponentieller Backoff-Algorithmus verwendet, um die Verzögerung zu bestimmen, 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ätigungen pro Sekunde sendet, stellt Pub/Sub Nachrichten alle 30 bis 60 Sekunden zu.
Beachten Sie die folgenden Hinweise zum Push-Backoff:
- Push-Backoffs können nicht aktiviert oder deaktiviert werden. Außerdem können Sie die Werte, die zur Berechnung der Verzögerung verwendet werden, nicht ändern.
- Senden Sie Backoff-Trigger für die folgenden Aktionen:
- Wenn eine negative Bestätigung empfangen wird.
- Wenn die Bestätigungsfrist einer Nachricht abläuft.
- Die Push-Aussetzung gilt für alle Nachrichten in einem Abo (global).
Zustellungsrate
Pub/Sub passt die Anzahl der gleichzeitigen Push-Anfragen mithilfe eines Algorithmus für einen langsamen Start an. Die maximal zulässige Anzahl an gleichzeitigen Push-Anfragen ist das Push-Fenster. Das Push-Fenster erhöht sich bei jeder erfolgreichen Übermittlung und verringert sich bei jedem Fehler. Das System beginnt mit einer kleinen Fenstergröße mit einer einzigen Ziffer.
Wenn ein Abonnent Nachrichten bestätigt, wird das Fenster exponentiell erhöht. Bei Abos, bei denen mehr als 99% der Nachrichten von den Abonnenten bestätigt werden und die durchschnittliche Latenz weniger als eine Sekunde beträgt, sollte das Push-Fenster so weit erweitert werden, dass es dem Publish-Durchsatz entspricht.
Die Latenz der Push-Anfrage umfasst Folgendes:
Die Umlauflatenz zwischen Pub/Sub-Servern und dem Push-Endpunkt
Die Verarbeitungszeit des Abonnenten
Nach 3.000 ausstehenden Nachrichten pro Region erhöht sich das Fenster linear,um zu verhindern, dass der Push-Endpunkt zu viele Nachrichten erhält. Wenn die durchschnittliche Latenz mehr als eine Sekunde beträgt oder der Abonnent weniger als 99% der Anfragen bestätigt, sinkt 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 Kontingent- und Ressourcenbeschränkungen.
Nächste Schritte
Erstellen Sie ein Push-Abo für Ihr Thema.
Erstellen oder ändern Sie ein Abo mit der gcloud CLI.
Mit REST APIs ein Abo erstellen oder ändern
Mit RPC APIs ein Abo erstellen oder ändern