Choisir un type d'abonnement

Ce document présente le fonctionnement des différents types d'abonnements dans Pub/Sub.

Aperçu de l'abonnement

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 clients abonnés. Toutefois, vous pouvez également activer la conservation des sujets pour permettre à un abonnement associé au sujet de remonter dans le temps et de relire les messages précédemment publiés. Le client abonné 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.

Workflow d'abonnement

  1. Une fois qu'un message a été envoyé à un abonné, celui-ci doit l'accuser réception.

  2. Si un message est distribué et qu'un abonné n'a pas encore confirmé qu'il l'a bien compris, il s'agit d'un message en attente.

  3. Pub/Sub tente à plusieurs reprises de distribuer un message qui n'a pas encore été confirmé. Cependant, Pub/Sub tente de ne pas transmettre de message en cours à un autre abonné ayant le même abonnement.

  4. L'abonné dispose d'un délai configurable et limité, appelé ackDeadline, pour accuser réception du message en attente. Une fois le délai écoulé, le message n'est plus considéré comme en attente et Pub/Sub tente de renvoyer le message.

Types d'abonnements

Lorsque vous créez un abonnement, vous devez spécifier le type de distribution des messages. Pub/Sub propose deux types de distribution de messages qui correspondent aux deux types d'abonnement suivants. Chaque type d'abonnement est décrit brièvement dans les sections suivantes de ce document.

  • Abonnement pull
  • Abonnement push

Vous pouvez modifier le type d'abonnement à tout moment.

Abonnement pull

Dans le cadre d'un abonnement pull, votre client abonné lance une requête auprès d'un serveur Pub/Sub pour récupérer les messages à l'aide de l'API REST Pull, de l'API RPC PullRequest, de l'API RESTStreamingPullRequest ou de l'API RPCStreamingPullRequest. La plupart des clients abonnés n'effectuent pas directement ces requêtes et s'appuient plutôt sur la bibliothèque cliente de haut niveau fournie par Google Cloud qui effectue des flux de requêtes d'extraction en interne et distribue les messages de manière asynchrone. Pour un client abonné qui a besoin de mieux contrôler la façon dont les messages sont extraits, Pub/Sub utilise une bibliothèque gRPC de bas niveau et générée automatiquement pour effectuer directement des demandes d'extraction ou de streaming. Ces requêtes peuvent être synchrones ou asynchrones.

Les deux images suivantes illustrent le workflow entre un client abonné et un abonnement pull.

Flux de messages pour un abonnement pull
Figure 1. Workflow d'un abonnement pull


Flux de messages pour un abonnement StreamingPull
Figure 2. Workflow pour un abonnement pull en streaming

Le workflow d'extraction est illustré dans la figure 1 et se présente comme suit:

  1. Le client abonné appelle explicitement la méthode pull, qui demande la distribution des messages. Cette requête correspond à la demande d'extraction, comme illustré sur l'image.

  2. Le serveur Pub/Sub répond avec zéro ou plusieurs messages, ainsi que des ID de confirmation. Une réponse sans message ou avec une erreur n'indique pas nécessairement qu'aucun message n'est disponible. Cette réponse est la PullResponse comme illustré dans l'image.

  3. Le client abonné appelle explicitement la méthode confirmée en utilisant l'ID de confirmation renvoyé pour confirmer que le message est traité et n'a pas besoin d'être de nouveau distribué. Il s'agit de l'AckRequest, comme illustré dans l'image.

La principale différence entre les flux de travail pull et pull est que, pour une seule demande d'extraction en flux continu, un client abonné peut recevoir plusieurs réponses, car il existe une connexion ouverte. En revanche, une seule réponse est renvoyée pour chaque demande d'extraction.

Pour en savoir plus sur le fonctionnement de l'abonnement pull et pour découvrir des exemples de configuration, consultez la section Abonnements pull.

Abonnement push

Dans le cas d'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 au client abonné via un point de terminaison préconfiguré. Cette requête s'affiche en tant que PushRequest dans l'image.

  2. Le point de terminaison accuse réception du message et renvoie un code de réussite HTTP. Si le message n'aboutit pas, cela indique que le message doit être renvoyé. Cette réponse apparaît sous la forme d'une réponse PushResponse dans l'image.

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

Pour en savoir plus sur le fonctionnement de l'abonnement push et sur des exemples de configuration, consultez la section Abonnements Push.

Choisir votre type d'abonnement

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

  Pull Push
Cas d'utilisation
  • Volume de messages important (plus d'un par seconde).
  • L'efficacité et le débit du traitement des messages sont essentiels.
  • Environnements dans lesquels un point de terminaison HTTPS public avec un certificat SSL non autosigné n'est pas possible.
  • Plusieurs sujets doivent être traités par le même webhook.
  • Abonnés à l'environnement standard App Engine et Cloud Functions
  • Environnements dans lesquels les dépendances Google Cloud (telles que les identifiants et la bibliothèque cliente) ne peuvent pas être configurées.
Points de terminaison Tout appareil connecté à Internet et disposant d'identifiants autorisés peut appeler l'API 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 Pub/Sub, de sorte que les messages de plusieurs abonnements peuvent être envoyés à un seul point de terminaison.
Équilibrage de charge Plusieurs abonnés peuvent passer des appels d'extraction au même abonnement partagé. Chaque abonné reçoit 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 nécessaire pour les applications App Engine du même projet que l'abonné.
La validation des points de terminaison push n'est pas nécessaire dans Google Cloud Console. Les points de terminaison doivent être accessibles à l'aide de noms DNS et avoir des certificats SSL installés.
Contrôle de flux Le client abonné contrôle la vitesse de diffusion. L'abonné peut modifier de manière dynamique le délai de confirmation, ce qui permet un traitement arbitraire des messages. Le serveur Pub/Sub applique un contrôle de flux automatiquement. Il n'est pas nécessaire de gérer le flux de messages côté client. Il est toutefois possible d'indiquer que le client ne peut pas gérer le chargement de messages actuel en renvoyant une erreur HTTP.
Efficacité et débit Atteint un débit élevé avec une faible capacité de processeur et de bande passante grâce à la livraison par lots et aux accusés de réception, ainsi qu'une consommation massivement parallèle. Cette méthode peut s'avérer inefficace si les sondages sont utilisés de façon agressive pour réduire le délai de distribution des messages. Envoie un message par requête et limite le nombre maximal de messages en attente.

Propriétés d'abonnement par défaut

Par défaut, Pub/Sub propose au moins une distribution sans garantie de commande sur tous les types d'abonnements. Si les messages présentent la même clé de tri et qu'ils se trouvent dans la même région, vous pouvez également activer le tri des messages. Une fois la propriété d'ordre des messages définie, le service Pub/Sub diffuse les messages dont la clé est identique à celle du service Pub/Sub.

Pub/Sub est également compatible avec la distribution exacte une fois en mode Aperçu.

En général, Pub/Sub diffuse chaque message une fois et dans l'ordre dans lequel il a été publié. Cependant, les messages peuvent parfois être distribués plusieurs fois dans un certain ordre. Si vous avez plusieurs diffusions, votre abonné doit être idempotent pour traiter les messages.

Expiration de l'abonnement

Par défaut, les abonnements expirent au bout de 31 jours d'inactivité de l'abonné ou en l'absence de mise à jour. Voici quelques exemples d'activités d'abonnés : connexions ouvertes, récupérations actives ou transferts réussis. Si Pub/Sub détecte une activité d'abonné ou une mise à jour des propriétés d'abonnement, l'horloge de suppression d'abonnement redémarre. À l'aide de règles d'expiration des abonnements, vous pouvez configurer la durée d'inactivité ou le rendre persistant quelle que soit l'activité. Vous pouvez également supprimer un abonnement manuellement.

Bien que vous puissiez créer un abonnement portant le même nom qu'un abonnement supprimé, le nouvel abonnement n'a aucun lien avec l'ancien. 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 Créer et utiliser des abonnements.

Étapes suivantes