Abonnements Push

Ce document présente un abonnement push, son workflow et les 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 envoyés à un serveur adressable publiquement ou à un webhook, comme une requête HTTPS POST.

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

Avant de commencer

Avant de lire ce document, assurez-vous de connaître les éléments suivants:

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

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

Workflow des abonnements push

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

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

Flux des 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 destinée au client abonné, à un point de terminaison préconfiguré. Cette requête est représentée par un 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 s'affiche sous la forme d'un 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 la façon dont vous écrivez des messages dans votre abonnement. Pour en savoir plus, consultez les 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 avec retour à la ligne.

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

Les exemples suivants montrent un corps encapsulé d'une requête POST JSON à 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 affiche les valeurs maximales actuelles, qui peuvent changer au fil du temps. De plus, la carte des attributs peut contenir différentes 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 ce 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 à diffuser des messages à l'aide d'un intervalle entre les tentatives push. Lorsque Pub/Sub utilise un intervalle push, il cesse de diffuser les messages pendant une durée prédéterminée. Cette période peut aller de 100 millisecondes à 60 secondes. Une fois le délai écoulé, Pub/Sub recommence à diffuser des messages.

L'intervalle entre les tentatives push utilise un algorithme d'intervalle exponentiel entre les tentatives pour déterminer le délai que Pub/Sub utilise entre l'envoi de 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 le délai avant envoi:

  • Vous ne pouvez pas activer ni désactiver le délai de diffusion. Vous ne pouvez pas non plus modifier les valeurs utilisées pour calculer le délai.
  • Déclenchez des déclencheurs de report sur les actions suivantes :
    • Lorsqu'un accusé de réception négatif est reçu.
    • Lorsque le délai de confirmation d'un message expire.
  • Le délai avant envoi des notifications 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. 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 avec 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 avec une latence moyenne des requêtes push inférieure à une seconde, la fenêtre d'envoi doit être suffisamment étendue 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éez un abonnement push pour votre sujet.

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

  • Créez ou modifiez un abonnement avec la gcloud CLI.

  • Créez ou modifiez un abonnement à l'aide d'API REST.

  • Créez ou modifiez un abonnement à l'aide des API RPC.