Présentation des abonnements

Ce document présente le fonctionnement des abonnements dans Cloud Pub/Sub. Pour en savoir plus sur les abonnements de distribution en mode pull et push, consultez les pages Guide pour les abonnés – Mode pull et Guide pour les abonnés – Mode push.

Pour recevoir des messages publiés dans un sujet, vous devez créer un abonnement associé à ce sujet. Seuls les messages publiés dans le sujet après la création de l'abonnement sont disponibles pour les applications d'abonnés. L'abonnement connecte le sujet à une application d'abonnés, qui reçoit et traite les messages publiés dans le sujet. Un sujet peut être associé à plusieurs abonnements, mais un abonnement donné ne peut être associé qu'à un seul sujet.

Pour en savoir plus sur la création et la mise à jour des abonnements, consultez la page Gérer les sujets et les abonnements.

Distribution de type "au moins une fois"

Cloud Pub/Sub distribue chaque message publié au moins une fois pour chaque abonnement. Il existe certaines exceptions à ce comportement de type "au moins une fois" :

  • Par défaut, un message qui ne peut pas être distribué pendant la durée de conservation maximale de sept jours est supprimé et n'est plus accessible. Cela se produit habituellement lorsque les abonnés ne suivent pas le rythme du flux de messages. Notez que vous pouvez configurer la durée de conservation des messages (la plage va de 10 minutes à 7 jours). Consultez la section Rouvrir et supprimer des messages pour en savoir plus sur les paramètres de conservation des messages.
  • Un message publié avant la création d'un abonnement donné ne sera généralement pas distribué pour cet abonnement. Ainsi, un message publié dans un sujet sans abonnement ne sera distribué à aucun abonné.

Une fois qu'un message est envoyé à un abonné, celui-ci doit en accuser réception. Un message est considéré comme en attente une fois qu’il a été envoyé pour distribution et avant qu’un abonné en ait accusé la réception. Cloud Pub/Sub tentera à plusieurs reprises de distribuer tout message dont la réception n'a pas été confirmée. Cependant, lorsqu'un message est en attente pour un abonné, Cloud Pub/Sub tente de ne pas le distribuer à un autre abonné du même abonnement. L'abonné dispose d'un délai configurable et limité, appelé ackDeadline, pour accuser réception du message en attente. Une fois la date limite écoulée, le message n'est plus considéré comme étant en attente et Cloud Pub/Sub tente de redistribuer le message.

En principe, Cloud Pub/Sub distribue chaque message une seule fois et dans l’ordre dans lequel il a été publié. Cependant, les messages peuvent parfois être distribués dans le désordre ou plus d'une fois. En général, l'application d'une distribution de type "plusieurs fois" nécessite que votre abonné soit idempotent lors du traitement des messages. Vous pouvez effectuer un traitement de type "exactement une fois" des flux de messages Cloud Pub/Sub en utilisant Cloud Dataflow PubsubIO. PubsubIO supprime les messages en double sur les identifiants de messages personnalisés ou ceux attribués par Cloud Pub/Sub. Vous pouvez également réaliser un traitement ordonné avec Cloud Dataflow en utilisant les API de tri standards du service. Sinon, pour obtenir l'ordonnancement, l'éditeur du sujet auquel vous vous abonnez peut inclure un jeton de séquence dans le message. Pour en savoir plus, consultez la page Ordonnancement des messages.

Distribution pull ou push

Un abonnement peut utiliser le système pull ou push pour la distribution des messages. Vous avez la possibilité de modifier ou de configurer le type de système à tout moment.

Abonnement pull

Dans le cadre d'une distribution pull, votre application d'abonnés lance des requêtes au serveur Cloud Pub/Sub pour récupérer les messages.

  1. L'application d'abonnés appelle de manière explicite la méthode pull, qui demande la distribution des messages.
  2. Le serveur Cloud Pub/Sub renvoie le message (ou une erreur si la file d'attente est vide), ainsi qu'un ID de confirmation.
  3. L'abonné appelle de manière explicite la méthode de confirmation à l'aide de l'ID de confirmation renvoyé pour accuser réception du message.

Flux des requêtes de messages pour un abonnement pull

Abonnement push

Dans le cas d'une distribution push, Cloud Pub/Sub lance des requêtes à l'application d'abonnés pour distribuer des messages.

  1. Le serveur Cloud Pub/Sub envoie chaque message en tant que requête HTTPS destinée à l'application d'abonnés, à un point de terminaison préconfiguré.
  2. Le point de terminaison accuse réception du message en renvoyant un code d'état HTTP positif. Une réponse négative indique que le message doit être renvoyé.

Flux des requêtes de messages pour un abonnement push

Cloud Pub/Sub ajuste de manière dynamique la fréquence des requêtes push en fonction du taux de réception de réponses positives.

Consultez le tableau suivant qui vous aidera à choisir le système de distribution approprié pour votre application :

Pull Push
  • Nombre élevé de messages (bien au-delà de 1/seconde).
  • L'efficacité et le débit du traitement des messages sont essentiels.
  • Un point de terminaison HTTPS public, avec un certificat SSL non autosigné, ne peut pas être configuré.
  • Plusieurs sujets qui doivent être traités par le même webhook
  • Abonnés à l'environnement standard App Engine et Cloud Functions
  • Environnements où les dépendances de Google Cloud Platform (telles que les identifiants et la bibliothèque cliente) ne peuvent pas être configurées

Vous trouverez un comparatif des distributions pull et push dans le tableau suivant :

  Pull Push
Points de terminaison Tout appareil connecté à Internet et disposant d'identifiants autorisés peut appeler l'API Cloud Pub/Sub. Un serveur HTTPS disposant d'un certificat non autosigné accessible sur le Web public. Le point de terminaison de réception peut être dissocié de l'abonnement Cloud Pub/Sub. Ainsi, les messages provenant de plusieurs abonnements peuvent être envoyés à un seul point de terminaison.
Équilibrage de charge Plusieurs abonnés peuvent effectuer des appels pull au même abonnement "partagé". Chaque abonné reçoit alors un sous-ensemble des messages. Le point de terminaison push peut être un équilibreur de charge.
Configuration Aucune configuration n'est requise. Aucune configuration n'est requise pour les applications App Engine au sein du même projet que l'abonné.
La configuration et la validation des points de terminaison push sont nécessaires pour tous les autres points de terminaison, depuis la console Google Cloud Platform. Les points de terminaison doivent être accessibles via des noms DNS. Des certificats SSL doivent également y être installés.
Contrôle de flux Le client abonné contrôle la fréquence de distribution. L'abonné peut modifier de façon dynamique le délai de confirmation, permettant ainsi de prolonger de manière arbitraire le traitement des messages. Le serveur Cloud Pub/Sub applique un contrôle de flux automatiquement. Le client n'a donc pas besoin de gérer le flux des messages. Il est toutefois possible d'indiquer que le client ne peut pas gérer la charge actuelle de messages en renvoyant une erreur HTTP.
Efficacité et débit Atteint un débit élevé avec un processeur et une bande passante peu exploités, permettant ainsi une distribution et des accusés de réception groupés, ainsi qu'une consommation massivement parallèle. Peut être inefficace si une scrutation agressive est utilisée pour réduire le délai de distribution des messages. Distribue un message par requête et limite le nombre maximal de messages en attente.

Cycle de vie d'un abonnement

Par défaut, les abonnements expirent après 31 jours d'inactivité (par exemple, en l'absence de connexions actives, de requêtes pull ou de réussites push). Si Cloud Pub/Sub détecte une activité d'abonné, l'horloge de suppression d'abonnement redémarre. À l'aide de règles d'expiration des abonnements (version bêta), vous pouvez configurer la durée d'inactivité ou rendre l'abonnement persistant, quelle que soit l'activité. Vous pouvez également supprimer un abonnement manuellement.

Même si vous avez la possibilité de créer des abonnements portant le même nom qu'un abonnement supprimé, sachez que le nouvel abonnement n'aura aucun rapport avec l'ancien, même s'ils ont le même nom. Même si l'abonnement supprimé comportait un grand nombre de messages non confirmés, un nouvel abonnement portant le même nom n'aurait aucun message en attente de distribution au moment de sa création.

Pour en savoir plus sur l'utilisation des abonnements, consultez la section Configurer les abonnements.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…