Abonnements Push

Ce document présente un abonnement push, son workflow et les propriétés associées.

Lors de la distribution push, Pub/Sub lance des requêtes à votre application d'abonné pour distribuer des messages. Les messages sont distribués à un serveur adressable publiquement ou à un webhook, comme une requête HTTPS POST.

Les abonnements push minimisent les dépendances aux bibliothèques clientes et aux mécanismes d'authentification spécifiques à Pub/Sub. Elles fonctionnent également avec les technologies de services sans serveur et d'autoscaling, telles que Cloud Functions, Cloud Run et Google Kubernetes Engine.

Avant de commencer

Avant de lire ce document, veillez à prendre connaissance des informations suivantes:

  • Fonctionnement de Pub/Sub et des différents termes Pub/Sub

  • Les différents types d'abonnements compatibles avec Pub/Sub et les raisons pour lesquelles vous pourriez vouloir utiliser un abonnement push.

Workflow d'abonnement push

Dans un abonnement push, un serveur Pub/Sub lance une requête à votre client abonné pour distribuer des messages.

L'image suivante illustre le workflow entre un client abonné et un abonnement push.

Flux de messages pour un abonnement push
Figure 3. Workflow pour un abonnement push

Voici une brève description du workflow qui fait référence à la Figure 3:

  1. Le serveur Pub/Sub envoie chaque message en tant que requête HTTPS au client abonné, sur un point de terminaison préconfiguré. Cette requête est affichée en tant que PushRequest dans l'image.
  2. Le point de terminaison accuse réception du message en renvoyant un code d'état HTTP de réussite. Une réponse infructueuse indique que Pub/Sub doit renvoyer les messages. Cette réponse est affichée en tant que PushResponse dans l'image.
  3. Pub/Sub ajuste dynamiquement le taux de requêtes push en fonction de la fréquence à laquelle il reçoit des réponses positives.

Propriétés d'un abonnement push

Les propriétés que vous configurez pour un abonnement push déterminent la manière dont vous écrivez des messages dans votre abonnement. Pour en savoir plus, consultez Propriétés des abonnements.

Comment les points de terminaison push reçoivent les messages

Lorsque Pub/Sub diffuse un message à un point de terminaison push, vous pouvez choisir de l'envoyer encapsulé ou encapsulé. Par défaut, les messages sont encapsulés.

  • Enveloppé. Pub/Sub envoie le message dans le corps JSON d'une requête POST.
  • Déballé. Pub/Sub envoie les données du message brut directement en tant que corps HTTP.

L'exemple suivant est le corps encapsulé d'une requête JSON POST envoyée à un point de terminaison push contenant la chaîne Hello there dans le champ message.data:

Le corps d'une requête POST est un objet JSON. Les données du message se trouvent dans le champ message.data et sont encodées en base64.

  {
      "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"
  }

Pour recevoir des messages d'abonnements push, utilisez un webhook et traitez les requêtes POST envoyées par Pub/Sub au point de terminaison push. Pour en savoir plus sur le traitement de ces requêtes POST dans App Engine, consultez la page Écrire des messages Pub/Sub et y répondre.

Après avoir reçu une requête push, renvoyez un code d'état HTTP. Pour accuser réception du message, renvoyez l'un des codes d'état suivants :

  • 102
  • 200
  • 201
  • 202
  • 204

Pour envoyer un accusé de réception négatif au message, renvoyez tout autre code d'état. Si vous envoyez un accusé de réception négatif ou si le délai d'accusé de réception expire, Pub/Sub renvoie le message. Vous ne pouvez pas modifier le délai de confirmation des messages individuels que vous recevez des abonnements push.

Authentification pour les abonnements push

Si un abonnement push utilise l'authentification, le service Pub/Sub signe un jeton JWT et l'envoie dans l'en-tête d'autorisation de la requête push.

Pour en savoir plus sur la configuration de l'authentification, consultez Authentifier les requêtes push.

Arrêter et reprendre la distribution des messages

Pour empêcher temporairement l'envoi de requêtes par Pub/Sub au point de terminaison push, passez l'abonnement en mode pull. Le changement peut prendre plusieurs minutes.

Pour reprendre la distribution push, définissez à nouveau l'URL sur un point de terminaison valide. Pour arrêter définitivement la distribution, supprimez l'abonnement.

Intervalle entre les tentatives d'envoi push

Si un abonné push envoie trop d'accusés de réception négatifs, Pub/Sub peut commencer à distribuer des messages à l'aide d'un intervalle entre les tentatives push. Lorsque Pub/Sub utilise un intervalle entre les tentatives push, il arrête de distribuer des messages pendant une durée prédéterminée. Cette durée peut être comprise entre 100 millisecondes et 60 secondes. Une fois le délai écoulé, Pub/Sub diffuse à nouveau des messages.

L'intervalle entre les tentatives de retransmission est basé sur un algorithme d'intervalle exponentiel entre les tentatives pour déterminer le délai entre deux envois de messages par Pub/Sub. Ce délai est calculé en fonction du nombre d'accusés de réception négatifs envoyés par les abonnés.

Par exemple, si un abonné push reçoit cinq messages par seconde et envoie un accusé de réception négatif par seconde, Pub/Sub diffuse des messages toutes les 500 millisecondes environ. Si l'abonné push envoie cinq accusés de réception négatifs par seconde, Pub/Sub diffuse des messages toutes les 30 à 60 secondes.

Notez les points suivants concernant l'intervalle entre les tentatives:

  • Vous ne pouvez pas activer ni désactiver l'intervalle entre les tentatives. Vous ne pouvez pas non plus modifier les valeurs utilisées pour calculer le délai.
  • Déclencheurs d'intervalle entre les tentatives pour les actions suivantes :
    • Lorsqu'un accusé de réception négatif est reçu.
    • Délai de confirmation d'un message expiré
  • L'intervalle push s'applique à tous les messages d'un abonnement (mondial).

Rythme de distribution

Pub/Sub ajuste le nombre de requêtes push simultanées à l'aide d'un algorithme de démarrage lent. Le nombre maximal autorisé de requêtes push simultanées est la fenêtre push. La fenêtre push augmente en cas de diffusion réussie et diminue en cas d'échec. Le système commence par une petite taille de fenêtre à un chiffre.

Lorsqu'un abonné accuse réception des messages, la fenêtre augmente de manière exponentielle. Pour les abonnements dont les abonnés accusent réception de plus de 99% des messages et dont la latence moyenne des requêtes push est inférieure à une seconde, la fenêtre push doit se développer suffisamment pour s'adapter au débit de publication.

La latence des requêtes push inclut les éléments suivants :

Après 3 000 messages en attente par région, la fenêtre augmente de manière linéaire pour éviter que le point de terminaison push ne reçoive trop de messages. Si la latence moyenne dépasse une seconde ou si l'abonné accuse moins de 99% des requêtes, la fenêtre passe à la limite inférieure de 3 000 messages en attente.

Pour plus d'informations sur les métriques que vous pouvez utiliser pour surveiller la diffusion push, consultez la section Surveiller les abonnements push.

Quotas et limites

Les abonnements push sont soumis à un ensemble de quotas et de limites de ressources.

Étapes suivantes

  • Créez un abonnement push à votre sujet.

  • Créer ou modifier un abonnement avec gcloud CLI

  • créer ou modifier un abonnement avec les API REST ;

  • créer ou modifier un abonnement avec les API RPC ;