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 de messages. Un service Pub/Sub repose sur quelques concepts clés, expliqués à l'aide de la figure suivante.
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 : une entité nommée qui régit le format des données d'un message Pub/Sub.
Abonnement : une 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 :
Deux applications d'éditeur, Éditeur 1 et Éditeur 2, envoient des messages à un seul sujet Pub/Sub. Éditeur 1 envoie le message A et Éditeur 2 envoie le message B.
Le sujet lui-même est associé à deux abonnements. Il s'agit de Abonnement 1 et Abonnement 2.
Le sujet est également associé à un schéma.
Chaque abonnement reçoit une copie des messages A et B du sujet.
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, Abonné 1 reçoit le message B , tandis que Abonné 2 reçoit le message A du sujet.
Abonnement 2 n'est associé qu'à une seule application d'abonnés appelée Abonné 3. Par conséquent, Abonné 3 reçoit tous les messages du sujet.
Durée de vie d'un message
Supposons qu'un seul client éditeur soit associé à un sujet. Le sujet est associé à un seul abonnement. Un seul abonné est associé à l'abonnement.
Les étapes suivantes décrivent le flux d'un message dans Pub/Sub :
Une application d'éditeur envoie un message à un sujet Pub/Sub.
Le message est enregistré dans l'espace de stockage.
En même temps qu'il enregistre 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.
L'abonnement envoie le message à une application d'abonnés associée.
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 distribué à nouveau.
Un message peut avoir trois états dans un service Pub/Sub :
Messages confirmés (acked) Une fois qu'une application d'abonnés a traité 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 (unacked) Si Pub/Sub ne reçoit pas d'accusé de réception avant l'expiration du 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 ou l'accusé de réception peut être perdu en raison de problèmes réseau temporaires. Un message non confirmé continue d'être distribué jusqu'à l'expiration de la durée de conservation des messages depuis sa publication. À ce stade, le message expire.
Messages confirmés négativement (nacked) Lorsqu'un abonné confirme négativement un message, Pub/Sub le distribue à nouveau immédiatement en fonction des paramètres de nouvelle tentative par défaut, qui peuvent être modifiés. Lorsqu'un abonné confirme négativement des messages non valides ou lorsqu'il ne peut pas les traiter, il s'assure que ces messages ne sont pas perdus et qu'ils sont traités correctement. Vous pouvez utiliser modifyAckDeadline avec la valeur 0 pour confirmer négativement un message.
Choisir un modèle de publication et d'abonnement Pub/Sub
Lorsque plusieurs clients éditeurs et abonnés Pub/Sub sont présents, vous devez également choisir le type d'architecture de publication et d'abonnement que vous souhaitez configurer.
Voici quelques-uns des modèles de publication et d'abonnement Pub/Sub compatibles :
Distribution unique (plusieurs à un) Dans cet exemple, plusieurs applications d'éditeur publient des messages dans un seul sujet. Ce sujet unique est associé à un seul abonnement. L'abonnement est à son tour associé à une seule application d'abonnés qui reçoit tous les messages publiés dans le sujet.
Équilibrage de charge (plusieurs à plusieurs) Dans cet exemple, une ou plusieurs applications d'éditeur publient des messages dans un seul sujet. Ce sujet unique est associé à un seul abonnement qui est à son tour associé à 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és 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 les messages du même abonnement.
Distribution ramifiée (un à plusieurs) Dans cet exemple, une ou plusieurs applications d'éditeur publient des messages dans un seul sujet. Ce sujet unique est associé à plusieurs abonnements. Chaque abonnement est associé à une seule application d'abonnés. Chacune des applications d'abonnés reçoit le même ensemble de messages publiés du sujet. Lorsqu'un sujet comporte plusieurs abonnements, chaque message doit être envoyé à un abonné qui reçoit des messages pour le compte de chaque abonnement. Si vous devez effectuer différentes opérations de 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 é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 :
- Google Cloud Console
- 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 Google Cloud console et que vous souhaitez tester
Pub/Sub, utilisez la console ou le gcloud CLI.
La bibliothèque cliente de haut niveau est recommandée lorsque vous avez besoin d'un débit élevé et d'une faible latence avec une surcharge opérationnelle et un coût 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 qui intervient lorsque vous utilisez directement les API de service.
Pour utiliser les bibliothèques clientes de haut niveau, consultez Bibliothèques clientes Pub/Sub.
Pour utiliser directement les bibliothèques clientes générées automatiquement de bas niveau, consultez Présentation des API Pub/Sub.
Voici quelques bonnes pratiques concernant l'utilisation des bibliothèques clientes :
Choisissez le bon langage de 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 nécessaires 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 langage.
Réutilisez les clients éditeurs. Lorsque vous publiez des 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 sujet.
Configurer Pub/Sub
Voici les étapes de haut niveau pour configurer Pub/Sub :
Créez ou choisissez un Google Cloud projet dans lequel vous pouvez configurer Pub/Sub.
Activez l'API Pub/Sub.
Obtenez les rôles et autorisations requis pour exécuter Pub/Sub.
Créez un sujet.
Si la structure des messages est essentielle, définissez un schéma pour vos messages.
Associez le schéma au sujet.
Configurez un client éditeur qui peut publier des messages dans le sujet.
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é.
Choisissez un type d'abonnement en fonction de la façon dont vous souhaitez recevoir les messages.
Créez un abonnement pour le sujet choisi.
Configurez un client abonné qui peut recevoir des messages de l'abonnement.
Si nécessaire, configurez des options avancées de distribution des messages telles que la distribution exacte, la gestion des baux, la distribution ordonnée et le contrôle de flux.
Commencez à publier des messages de votre client éditeur dans le sujet.
Configurez simultanément votre client abonné pour recevoir et traiter 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 du projet ou au numéro du projet, disponible dans la Google Cloud console. Par exemple,my-cool-projectest un ID de projet.123456789123est un numéro de projet.collection: doit être défini surtopics,subscriptions,schemasousnapshots.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 de 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ópicon'est pas une valeur ID valide. En revanche,mi-t%C3%B3picoest une valeur valide. Ce format est important lorsque vous effectuez des appels REST.- Ne pas commencer par la chaîne
Étape suivante
Pour commencer à configurer Pub/Sub à l'aide de la gcloud CLI, consultez Guide de démarrage rapide : Publier et recevoir des messages dans Pub/Sub à l'aide de la gcloud CLI.
Pour commencer à configurer Pub/Sub à l'aide de la Google Cloud console, consultez Guide de démarrage rapide : Publier et recevoir des messages dans Pub/Sub à l'aide de la Google Cloud console.
Pour commencer à configurer Pub/Sub à l'aide des bibliothèques clientes, consultez Guide de démarrage rapide : Publier et recevoir des messages dans Pub/Sub à l'aide de la bibliothèque cliente.