Présentation du service Pub/Sub

Pub/Sub est un service de publication et d'abonnement (publish/subscribe ou Pub/Sub), c'est-à-dire un service de messagerie où les expéditeurs de messages sont découplés des destinataires. Un service Pub/Sub repose sur plusieurs concepts clés, qui sont expliqués à l'aide de la figure suivante.

Figure montrant les différents composants d'un service Pub/Sub et la façon dont ils sont interconnectés.
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 au service de messagerie (c'est-à-dire les publie) 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: entité nommée qui représente un intérêt à recevoir les messages associés à un sujet particulier

  • Abonné (également appelé consommateur): reçoit des messages dans le cadre d'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 des abonnements 1 et 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. L'abonnement 1 est associé à deux applications d'abonnés, Abonné 1 et Abonné 2. Les deux applications d'abonnés reçoivent un sous-ensemble des messages du sujet. Dans cet exemple, l'abonné 1 reçoit le message B, tandis que l'abonné 2 reçoit le message A du sujet.

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

Durée de vie d'un message

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

Illustration montrant le flux d'un message dans Pub/Sub.
Figure 2 : Un message passe d'un client éditeur à un client abonné via Pub/Sub.

Les étapes suivantes décrivent le flux d'un message dans Pub/Sub:

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

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

  3. En plus d'écrire le message dans son 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 son espace de stockage.

État d'un message dans Pub/Sub

Lorsqu'un message est en attente pour un abonné, Pub/Sub ne tente pas de 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 peut être à nouveau distribué.

Un message dans un service Pub/Sub peut avoir trois états:

  • Messages confirmés (acknowledged). Une fois qu'une application d'abonné traite un message envoyé d'un sujet à un abonnement, elle renvoie un accusé de réception à Pub/Sub. Si tous les abonnements d'un sujet ont accusé réception du 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 de confirmation, 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 imparti ou l'accusé de réception peut être perdu en raison de problèmes réseau temporaires. Un message non confirmé continue d'être diffusé jusqu'à l'expiration de la durée de conservation du message depuis sa publication. À ce stade, le message expire.

  • Messages avec accusé de réception négatif (nacked) Si un abonné nack un message, Pub/Sub le redélivre immédiatement. Lorsqu'un abonné nack des messages non valides ou qu'il ne peut pas les traiter, il contribue à s'assurer qu'ils ne sont pas perdus et qu'ils sont finalement traités correctement. Vous pouvez utiliser modifyAckDeadline avec une valeur de 0 pour refuser un message.

Choisir un modèle de publication/abonnement Pub/Sub

Lorsqu'il existe plusieurs clients éditeurs et abonnés Pub/Sub, 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 de publication/abonnement Pub/Sub compatibles:

  • Distribution unique (plusieurs à un). Dans cet exemple, plusieurs applications d'éditeurs publient des messages sur un même sujet. Ce seul sujet est associé à un seul abonnement. L'abonnement est, à son tour, associé à une seule application d'abonné qui reçoit tous les messages publiés dans le sujet.

  • Équilibré en charge (de nombreux à de nombreux). Dans cet exemple, une ou plusieurs applications d'éditeur publient des messages dans un même sujet. Ce seul sujet est associé à un seul abonnement qui, à son tour, est connecté à plusieurs applications d'abonnés. Chacune des applications d'abonnés reçoit un sous-ensemble des messages publiés, et aucune application d'abonné ne reçoit 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 vous devez prendre en charge davantage de messages, ajoutez des abonnés pour recevoir des messages du même abonnement.

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

Choisir une option de configuration Pub/Sub

Vous pouvez configurer un environnement Pub/Sub à l'aide de 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)

Le choix d'une option de configuration Pub/Sub dépend de votre cas d'utilisation.

Si vous ne connaissez pas la console Google Cloud et que vous souhaitez tester Pub/Sub, utilisez la console ou gcloud CLI.

La bibliothèque cliente de haut niveau est recommandée lorsque vous avez besoin d'un débit élevé et d'une latence faible avec un coût de traitement et des frais opérationnels 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 et intervient lorsque vous utilisez directement les API de service.

Voici quelques bonnes pratiques concernant l'utilisation des bibliothèques clientes:

  • Choisissez la bonne langue 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 la mise à l'échelle verticale 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 des corrections de bugs. Assurez-vous d'utiliser la dernière version de la bibliothèque cliente pour votre langue.

  • Réutiliser les clients de l'éditeur Lors de la publication de messages, il est plus efficace de réutiliser le même client éditeur au lieu de créer des clients éditeurs 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 comme Node, qui ne disposent pas d'un 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 de discussion.

Configurer Pub/Sub

Voici les étapes de haut niveau à 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 requis 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 des options de publication avancées telles que le contrôle de flux, la messagerie par lot et le contrôle de la simultanéité.

  9. Choisissez un type d'abonnement en fonction de la manière dont vous souhaitez recevoir 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 des options de distribution de messages avancées telles que la distribution exactement une fois, la gestion des baux, la distribution ordonnée et le contrôle de flux.

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

  14. Configurez simultanément votre client abonné pour qu'il reçoive et traite ces messages.

Consignes de dénomination d'un sujet, d'un abonnement, d'un schéma ou d'un instantané

Un nom attribué à une ressource Cloud Pub/Sub, comme un sujet, un abonnement, un schéma ou un instantané, permet d'identifier cette ressource de manière unique. 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 de 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 être défini sur topics, subscriptions, schemas ou snapshots.

  • ID: doit respecter les consignes 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 pourcentage %

    Vous pouvez utiliser les caractères spéciaux de la liste précédente dans les noms de ressources sans codage d'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 n'est pas un ID valide. En revanche, mi-t%C3%B3pico est valide. Ce format est important lorsque vous effectuez des appels REST.

Étape suivante