Présentation du service Pub/Sub

Pub/Sub est un publish/subscribe de publish/subscribe (publish/subscribe), c'est-à-dire un service de messagerie dans lequel les expéditeurs de messages sont découplés des destinataires. La figure suivante explique plusieurs concepts clés d'un service Pub/Sub.

Figure illustrant les différents composants d'un service Pub/Sub et la manière dont ils se connectent les uns aux autres.
Figure 1 : Deux clients éditeurs envoient deux messages différents à un sujet Pub/Sub commun.

Voici les composants d'un service Pub/Sub:

  • Éditeur (également appelé producteur): crée des messages et les envoie (publie) au service de messagerie dans un sujet spécifié.

  • Message : les données qui transitent par le service

  • Sujet : une entité nommée qui représente un flux de messages

  • Schéma: entité nommée qui régit le format de données d'un message Pub/Sub.

  • Abonnement: une entité nommée qui représente un intérêt à recevoir des messages sur un sujet particulier.

  • Abonné (également appelé consommateur): reçoit des messages sur un abonnement spécifié.

La procédure suivante décrit le workflow du service Pub/Sub:

  1. Deux applications d'éditeur, Éditeur 1 et Éditeur 2, envoient des messages à un seul sujet Pub/Sub. L'éditeur 1 envoie le message A et l'éditeur 2 envoie le message B.

  2. Le sujet lui-même est associé à deux abonnements. Il s'agit de l'abonnement 1 et de l'abonnement 2.

  3. Le sujet est également associé à un schéma.

  4. Chaque abonnement reçoit une copie des messages A et B du sujet.

  5. Abonnement 1 est connecté à deux applications d'abonné : Abonné 1 et Abonné 2. Les deux applications d'abonnés reçoivent un sous-ensemble des messages du sujet. Dans cet exemple, Abonné 1 reçoit le message B, tandis qu'Abonné 2 reçoit le message A du sujet.

  6. L'abonnement 2 n'est connecté qu'à une seule application d'abonné appelée Abonné 3. Ainsi, Abonné 3 reçoit tous les messages du sujet.

Cycle de vie d'un message dans Pub/Sub

Supposons qu'un seul client d'éditeur soit associé à un sujet. Le sujet est associé à un seul abonnement. Un seul abonné est connecté à l'abonnement.

Figure illustrant le flux d'un message dans Pub/Sub.
Figure 2 : un message est transmis d'un client éditeur à un client abonné via Pub/Sub.

Les étapes suivantes décrivent la circulation d'un message dans Pub/Sub:

  1. Une application d'éditeur envoie un message à un sujet Pub/Sub.

  2. Le message est enregistré dans l'espace de stockage.

  3. En plus d'écrire le message dans l'espace de stockage, Pub/Sub le distribue à tous les abonnements associés au sujet.

    Dans cet exemple, il s'agit d'un seul abonnement.

  4. L'abonnement envoie le message à une application d'abonné associée.

  5. L'abonné envoie un accusé de réception à Pub/Sub indiquant qu'il a traité le message.

    Une fois qu'au moins un abonné de chaque abonnement a accusé réception du message, Pub/Sub supprime le message de l'espace de stockage.

État d'un message dans Pub/Sub

Lorsqu'un message est en attente pour un abonné, Pub/Sub tente de ne pas le distribuer à un autre abonné du même abonnement. L'abonné dispose d'un temps limité configurable, 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 le redistribuer.

Il existe trois états pour un message dans un service Pub/Sub:

  • Messages confirmés Une fois qu'une application d'abonné a traité un message envoyé depuis un sujet vers un abonnement, elle renvoie un accusé de réception à Pub/Sub. Si tous les abonnements d'un sujet ont confirmé le message, celui-ci est supprimé de manière asynchrone de la source des messages à publier et de l'espace de stockage.

  • Messages non confirmés (non confirmés). Si Pub/Sub ne reçoit pas d'accusé de réception dans le délai imparti, un message peut être distribué plusieurs fois. Par exemple, l'abonné peut envoyer un accusé de réception après l'expiration du délai, ou cet accusé de réception peut être perdu en raison de problèmes temporaires de réseau. Un message non confirmé continue d'être distribué jusqu'à ce que sa durée de conservation expire depuis sa publication. À ce stade, le message expire.

  • Messages dont la confirmation est négative (nacked). Si un abonné signale un message, Pub/Sub le redistribue immédiatement. Lorsqu'un abonné perd des messages non valides ou lorsqu'il ne peut pas les traiter, il s'assure qu'ils ne sont pas perdus et qu'ils seront, à terme, traités avec succès. Vous pouvez utiliser modifyAckDeadline avec une valeur de 0 pour confirmer un message.

Choisir un modèle de publication et d'abonnement Pub/Sub

Lorsqu'il existe plusieurs clients éditeur et abonné, vous devez également choisir le type d'architecture de publication et d'abonnement que vous souhaitez configurer.

Figure illustrant différents modèles de publication et d'abonnement.
Figure 3 : Les relations éditeur-abonné peuvent être de type plusieurs à un (distribution unique), plusieurs à plusieurs (équilibrage de charge) et un à plusieurs (distribution ramifiée).

Voici quelques-uns des modèles d'abonnement et de publication Pub/Sub compatibles:

  • Mode ventilateur (plusieurs à un). Dans cet exemple, plusieurs applications d'éditeur publient des messages dans un seul sujet. Ce sujet est associé à un seul abonnement. L'abonnement est, à son tour, connecté à une seule application d'abonné qui récupère tous les messages publiés à partir du sujet.

  • Équilibrage de charge (plusieurs à plusieurs). Dans cet exemple, une ou plusieurs applications d'éditeur publient des messages dans un seul sujet. Ce sujet est associé à un seul abonnement, qui est lui-même connecté à plusieurs applications d'abonnement. Chacune des applications d'abonné reçoit un sous-ensemble des messages publiés, et deux applications d'abonné ne reçoivent pas le même sous-ensemble de messages. Dans ce cas d'équilibrage de charge, vous utilisez plusieurs abonnés pour traiter les messages à grande échelle. Si d'autres messages doivent être acceptés, vous devez ajouter d'autres abonnés pour qu'ils puissent recevoir des messages du même abonnement.

  • Fonctionnalité de distribution ramifiée (un à plusieurs). Dans cet exemple, une ou plusieurs applications d'éditeur publient des messages dans un seul sujet. Ce sujet est associé à plusieurs abonnements. Chaque abonnement est connecté à une seule application d'abonné. Chacune des applications d'abonnés reçoit le même ensemble de messages publiés à partir du sujet. Lorsqu'un sujet est associé à plusieurs abonnements, chaque message doit être envoyé à un abonné recevant des messages pour le compte de chaque abonnement. Si vous devez effectuer différentes opérations sur les données sur le même ensemble de messages, la distribution ramifiée est une bonne option. Vous pouvez également associer plusieurs abonnés à chaque abonnement et obtenir un sous-ensemble de messages à équilibrage de charge pour chaque abonné.

Choisir une option de configuration Pub/Sub

Vous pouvez configurer un environnement Pub/Sub en utilisant l'une des options suivantes:

  • Console Google Cloud
  • Google Cloud CLI
  • Bibliothèques clientes Cloud (bibliothèque cliente de haut niveau)
  • API REST et RPC (bibliothèque cliente de bas niveau)

L'option de configuration Pub/Sub que vous choisirez dépend de votre cas d'utilisation.

Si vous débutez dans la console Google Cloud et que vous souhaitez tester Pub/Sub, utilisez la console ou l'gcloud CLI.

La bibliothèque cliente de haut niveau est recommandée dans les cas où vous avez besoin d'un débit élevé et d'une faible latence, avec des coûts opérationnels et des coûts de traitement minimaux. Par défaut, la bibliothèque cliente de haut niveau utilise l'API StreamingPull. Les bibliothèques clientes de haut niveau contiennent des fonctions et des classes prédéfinies qui gèrent les appels d'API sous-jacents pour l'authentification, l'optimisation du débit et de la latence, la mise en forme des messages et d'autres fonctionnalités.

La bibliothèque cliente de bas niveau est une bibliothèque gRPC générée automatiquement. Elle entre en jeu lorsque vous utilisez directement les API de service.

Voici quelques bonnes pratiques pour utiliser les bibliothèques clientes:

  • Choisissez le langage approprié pour la bibliothèque cliente. Les performances des bibliothèques clientes Pub/Sub varient selon le langage. Par exemple, la bibliothèque cliente Java est plus efficace pour le scaling vertical que la bibliothèque cliente Python, et peut gérer un débit plus élevé. Java, C++ et Go sont des langages plus efficaces en termes de ressources de calcul requises pour gérer les charges de publication ou d'abonnement.

  • Utilisez la dernière version de la bibliothèque cliente. Les bibliothèques clientes Pub/Sub sont constamment mises à jour avec de nouvelles fonctionnalités et corrections de bugs. Assurez-vous d'utiliser la dernière version de la bibliothèque cliente pour votre langage.

  • Réutiliser les clients d'éditeurs. Lors de la publication de messages, il est plus efficace de réutiliser le même client d'éditeur que de créer d'autres clients d'éditeur pour chaque requête de publication. En effet, la première requête de publication après la création d'un client éditeur nécessite un certain temps pour établir une connexion autorisée. Dans certains langages, tels que Node, qui n'ont pas de client éditeur explicite, réutilisez l'objet sur lequel vous appelez la méthode de publication. Par exemple, dans Node, enregistrez et réutilisez l'objet "topic".

Configurer Pub/Sub

Voici les principales étapes à suivre pour configurer Pub/Sub:

  1. Créez ou choisissez un projet Google Cloud dans lequel vous pouvez configurer Pub/Sub.

  2. Activez l'API Pub/Sub.

  3. Obtenez les rôles et les autorisations nécessaires pour exécuter Pub/Sub.

  4. Créer un sujet

  5. Si la structure des messages est essentielle, définissez un schéma pour vos messages.

  6. Associez le schéma au sujet.

  7. Configurez un client éditeur pouvant publier des messages dans le sujet.

  8. Si nécessaire, configurez les options de publication avancées, telles que le contrôle de flux, la messagerie par lot et le contrôle de simultanéité.

  9. Choisissez un type d'abonnement selon le mode de réception des messages.

  10. Créez un abonnement pour le sujet choisi.

  11. Configurez un client abonné pouvant recevoir des messages de l'abonnement.

  12. Si nécessaire, configurez les options avancées de distribution des messages, telles que la distribution "exactement une fois", la gestion de la location, la distribution ordonnée et le contrôle de flux.

  13. Commencez à publier les messages de votre client éditeur dans le sujet.

  14. Simultanément, configurez votre client abonné pour qu'il reçoive et traite ces messages.

Consignes pour nommer un sujet, un abonnement, un schéma ou un instantané

Ce nom identifie de manière unique une ressource Pub/Sub, telle qu'un sujet, un abonnement, un schéma ou un instantané. Le nom de la ressource doit respecter le format suivant:

projects/project-identifier/collection/ID

  • project-identifier: doit correspondre à l'ID ou au numéro du projet, disponible dans la console Google Cloud. Par exemple, my-cool-project est un ID de projet. 123456789123 est un numéro de projet.

  • collection: doit correspondre à topics, subscriptions, schemas ou snapshots.

  • ID: doit respecter les directives suivantes:

    • Ne pas commencer par la chaîne goog
    • Commencer par une lettre
    • contenir entre 3 et 255 caractères ;
    • Ne contenir que les caractères suivants: lettres [A-Za-z], chiffres [0-9], tirets -, traits de soulignement _, points ., tildes ~, signes plus + et signes de pourcentage %

    Vous pouvez utiliser les caractères spéciaux de la liste précédente dans les noms de ressources sans encodage URL. Toutefois, vous devez vous assurer que tous les autres caractères spéciaux sont correctement encodés ou décodés lorsque vous les utilisez dans des URL. Par exemple, mi-tópico est un ID non valide. Toutefois, mi-t%C3%B3pico est valide. Ce format est important lorsque vous passez des appels REST.

Étapes suivantes