Abonnements Push

Ce document fournit une présentation d'un abonnement push, de son workflow et des propriétés associées.

Dans le cas d'une distribution push, Pub/Sub lance des requêtes à l'application d'abonnés 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 vis-à-vis des bibliothèques clientes et des mécanismes d'authentification spécifiques à Pub/Sub. Ils fonctionnent également bien avec les technologies de service sans serveur et à autoscaling, telles que les fonctions Cloud Run, Cloud Run et Google Kubernetes Engine.

Avant de commencer

Avant de lire ce document, assurez-vous de bien comprendre les points suivants :

  • Le fonctionnement de Pub/Sub et les différents termes associés.

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

Workflow d'un 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 d'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 destinée au client abonné, à un point de terminaison préconfiguré. Cette requête est représentée par 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 négative indique que Pub/Sub doit renvoyer les messages. Cette réponse est représentée par PushResponse dans l'image.
  3. Pub/Sub ajuste de manière dynamique la fréquence des requêtes push en fonction du taux de réception de réponses de réussite.

Propriétés d'un abonnement push

Les propriétés que vous configurez pour un abonnement push déterminent comment vous écrivez des messages dans votre abonnement. Pour en savoir plus, consultez la section Propriétés d'abonnement.

Comment les points de terminaison push reçoivent-ils des messages ?

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

  • Encapsulé Pub/Sub envoie le message dans le corps JSON d'une requête POST.
  • Non encapsulé Pub/Sub envoie directement les données brutes du message en tant que corps HTTP.

Les exemples suivants montrent un corps encapsulé d'une requête POST JSON vers 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.

Exemple de requête avec les valeurs minimales

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

Exemple de requête avec les valeurs maximales

Notez que cet exemple montre les valeurs maximales actuelles, qui peuvent changer au fil du temps. De plus, la carte d'attributs peut contenir une variété de valeurs.

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

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 pour le message, renvoyez n'importe quel autre code d'état. Si vous envoyez un accusé de réception négatif ou que le délai de confirmation 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 la section 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. La prise en compte de la modification 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 d'envoi push. Lorsque Pub/Sub utilise un intervalle entre les tentatives d'envoi push, il cesse de distribuer des messages pendant une durée prédéterminée. Cette durée peut varier de 100 millisecondes à 60 secondes. Une fois ce délai écoulé, Pub/Sub recommence à distribuer des messages.

L'intervalle entre les tentatives d'envoi push utilise un algorithme d'intervalle exponentiel entre les tentatives pour déterminer le délai utilisé par Pub/Sub entre l'envoi des messages. Cette durée est calculée en fonction du nombre d'accusés de réception négatifs envoyés par les abonnés push.

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. Ou, si l'abonné push envoie cinq accusés de réception négatifs par seconde, Pub/Sub diffuse les messages toutes les 30 à 60 secondes.

Notez les points suivants concernant l'intervalle entre les tentatives d'envoi push :

  • L'intervalle entre les tentatives d'envoi push ne peut pas être activé ni désactivé. Vous ne pouvez pas non plus modifier les valeurs utilisées pour calculer le délai.
  • L'intervalle entre les tentatives d'envoi push se déclenche lors des actions suivantes :
    • Lorsqu'un accusé de réception négatif est reçu.
    • Lorsque le délai de confirmation d'un message expire.
  • L'intervalle entre les tentatives d'envoi push s'applique à tous les messages d'un abonnement (global).

Rythme de distribution

Pub/Sub ajuste le nombre de requêtes push simultanées à l'aide d'un algorithme de démarrage progressif (Slow Start). Le nombre maximal autorisé de requêtes push simultanées correspond à la fenêtre push. La fenêtre push augmente pour toute distribution réussie et diminue pour tout échec. Le système commence par une petite taille de fenêtre à un seul 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 avec une latence moyenne des requêtes push inférieure à une seconde, la fenêtre push doit être suffisamment grande pour suivre le 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 façon 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 réception de moins de 99% des requêtes, la fenêtre se réduit à 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.

Étape suivante

  • Créer un abonnement push pour votre sujet.

  • Résoudre les problèmes liés à un abonnement push.

  • Créer ou modifier un abonnement avec la gcloud CLI.

  • Créer ou modifier un abonnement avec les API REST.

  • Créer ou modifier un abonnement avec les API RPC.