Abonnements Push

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

Dans le cadre d'une 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, tel qu'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 bien avec les technologies de service sans serveur et avec autoscaling, telles que Cloud Functions, Cloud Run et Google Kubernetes Engine.

Avant de commencer

Avant de lire ce document, assurez-vous de bien maîtriser les points suivants:

• le fonctionnement de Pub/Sub et les différents termes associés à Pub/Sub ;

• Les différents types d'abonnements acceptés par 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.

Figure 3. Workflow pour un abonnement push

Voici une brève description du workflow faisant 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 négative 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 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 manière dont vous écrivez des messages dans votre abonnement. Pour en savoir plus, consultez Propriétés d'abonnement.

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

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

• Une fois emballé, Pub/Sub envoie le message dans le corps JSON d'une requête POST.
• Désencapsulé Pub/Sub envoie les données brutes du message directement dans le corps HTTP.

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

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 indique les valeurs maximales actuelles, qui peuvent changer au fil du temps. En outre, le mappage d'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, 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 d'accusé de réception 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 du message

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 du 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. Lorsque Pub/Sub applique un intervalle entre les tentatives, il arrête la diffusion des messages pendant une durée prédéterminée. Cette période peut varier de 100 millisecondes à 60 secondes. Une fois ce délai écoulé, Pub/Sub recommence à distribuer des messages.

Remarque :Cette fonctionnalité est indépendante du Règlement concernant les nouvelles tentatives d'abonnement. Vous pouvez combiner ces deux fonctionnalités pour mieux contrôler le flux des messages. Dans ce cas, le délai total correspond à la valeur maximale combinée de la valeur de l'intervalle entre les tentatives et de la valeur de la stratégie de nouvelle tentative. Si vous remarquez des problèmes de distribution des messages, vérifiez comment votre stratégie de nouvelle tentative interagit avec l'intervalle entre les tentatives.

L'intervalle entre les tentatives 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.

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 distribue des messages toutes les 30 à 60 secondes.

Tenez compte des points suivants concernant l'intervalle entre les tentatives:

• L'intervalle entre les tentatives 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éclenche les 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 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 à démarrage lent. Le nombre maximal autorisé de requêtes push simultanées correspond à la fenêtre d'envoi. La fenêtre d'envoi augmente à chaque 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 où les abonnés accusent réception de plus de 99% des messages et présentent une latence moyenne des requêtes push inférieure à une seconde, la fenêtre push doit s'étendre suffisamment pour suivre le débit de publication.

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

• La latence du réseau aller-retour entre les serveurs Pub/Sub et le point de terminaison push

• Temps de traitement de l'abonné

Après 3 000 messages en attente par région, la fenêtre augmente linéairement 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 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 pour votre sujet.

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

• Créez ou modifiez un abonnement avec les API REST.

• Créez ou modifiez un abonnement avec les API RPC.