Abonnements Push

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

Les abonnements push minimisent les dépendances sur les bibliothèques clientes spécifiques à Pub/Sub des mécanismes d'authentification. 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 bien maîtriser ce qui suit:

• le 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 d'abonnement 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.

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 demande apparaît comme un PushRequest dans l'image.
2. Le point de terminaison accuse réception du message en renvoyant un état HTTP de réussite du code source. Une réponse négative indique que Pub/Sub doit renvoyer les messages. Cette réponse est affichée sous la forme d'un PushResponse dans le l'image.
3. Pub/Sub ajuste de manière dynamique la fréquence des requêtes push en fonction en fonction du taux de réception de réponses positives.

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 ?

Quand Pub/Sub distribue un message à un point de terminaison push, vous pouvez choisir de l'envoyer avec un emballage donné ou désemballé. Par défaut, les messages sont envoyés avec retour à la ligne.

• Encapsulé. Pub/Sub envoie le message dans le corps JSON d'une POST.
• Non empaquetée. Pub/Sub envoie les données brutes du message directement le corps HTTP.

Les exemples suivants illustrent le corps encapsulé d'une requête JSON POST à une requête push. point de terminaison 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 message.data et est encodée 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. En outre, la carte 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 au message, renvoyez tout autre état du code source. Si vous envoyez un accusé de réception négatif ou délai d'accusé de réception 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 cette 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 à 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 varier de 100 millisecondes à 60 secondes. Une fois le délai écoulé, Pub/Sub recommence à diffuser des messages.

Remarque : Cette fonctionnalité est indépendante de la stratégie de nouvelle tentative 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 combinée maximale des l'intervalle entre les tentatives et la valeur de la règle de nouvelle tentative. Si vous constatez des problèmes de diffusion de messages, vérifiez comment votre stratégie de nouvelle tentative interagit avec le délai avant expiration du push.

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

• L'intervalle 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 se déclenche 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.
• L'intervalle 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 de transfert augmente dès que la livraison est réussie diminue en cas de défaillance. 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 :

• La latence 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 s'étend linéairement jusqu'à empêcher le point de terminaison push de recevoir 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.

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

• créer ou modifier un abonnement à l'aide des API REST ;

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