Qu'est-ce que Pub/Sub et Pub/Sub Lite ?

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.
description: Fonctionnement de Pub/Sub et Pub/Sub Lite, ainsi que les différents termes qui y sont associés

Pub/Sub est un service de messagerie asynchrone et évolutif qui dissocie les services générant des messages de ceux qui les traitent.

Pub/Sub permet aux services de communiquer de manière asynchrone, avec des latences de l'ordre de 100 millisecondes.

Pub/Sub est utilisé pour les pipelines d'analyse de flux et d'intégration de données afin d'ingérer et de distribuer des données. Il est aussi efficace en tant que middleware de messagerie pour l'intégration de services ou en tant que file d'attente pour charger des tâches en parallèle.

Pub/Sub vous permet de créer des systèmes de producteurs et de consommateurs d'événements, appelés éditeurs et abonnés. Les éditeurs communiquent de manière asynchrone avec les abonnés en diffusant des événements plutôt que par des appels de procédure à distance (RPC) synchrones.

Les éditeurs envoient des événements au service Pub/Sub, indépendamment du mode ou du moment de leur traitement. Pub/Sub diffuse ensuite des événements à tous les services qui y réagissent. Dans les systèmes qui communiquent via des RPC, les éditeurs doivent attendre que les abonnés reçoivent les données. Toutefois, l'intégration asynchrone dans Pub/Sub augmente la flexibilité et la robustesse du système global.

Pour commencer à utiliser Pub/Sub, consultez le guide de démarrage rapide sur l'utilisation de la console Google Cloud. Pour une introduction plus complète, reportez-vous à la page Créer un système de messagerie Pub/Sub.

Cas d'utilisation courants

  • Ingestion des utilisateurs et événements du serveur. Pour utiliser les événements d'interaction utilisateur depuis des applications utilisateur ou des événements de serveur de votre système, vous pouvez les transférer vers Pub/Sub. Vous pouvez ensuite utiliser un outil de traitement par flux, tel que Dataflow, qui envoie les événements aux bases de données. Exemples : BigQuery, Cloud Bigtable et Cloud Storage. Pub/Sub vous permet de collecter des événements de nombreux clients simultanément.

  • Distribution d'événements en temps réel. Les événements, bruts ou traités, peuvent être mis à la disposition de plusieurs applications de votre équipe et de votre organisation pour un traitement en temps réel. Pub/Sub est compatible avec un "bus d'événement d'entreprise" et des modèles de conception d'applications basés sur des événements. Pub/Sub vous permet d'intégrer de nombreux systèmes Google qui exportent des événements vers Pub/Sub.

  • Réplication des données entre des bases de données. Pub/Sub est couramment utilisé pour distribuer des événements de modification à partir de bases de données. Ces événements permettent de créer une vue de l'état de la base de données et de l'historique des états dans BigQuery et d'autres systèmes de stockage de données.

  • Traitement en parallèle et workflows. Vous pouvez répartir efficacement de nombreuses tâches entre plusieurs nœuds de calcul en utilisant des messages Pub/Sub pour vous connecter à Cloud Functions. Il peut s'agir, par exemple, de compresser des fichiers texte, d'envoyer des notifications par e-mail, d'évaluer des modèles d'IA ou de reformater des images.

  • Bus d'événement d'entreprise. Vous pouvez créer un service de partage de données en temps réel à l'échelle de l'entreprise, en distribuant des événements commerciaux, des mises à jour de bases de données et des événements d'analyse au sein de votre organisation.

  • Streaming de données depuis des applications, des services ou des appareils IoT. Par exemple, une application SaaS peut publier un flux d'événements en temps réel. Un capteur résidentiel peut également diffuser des données vers Pub/Sub pour les utiliser dans d'autres produits Google Cloud via un pipeline Dataflow.

  • Actualisation des caches distribués. Par exemple, une application peut publier des événements d'invalidation pour mettre à jour les ID d'objets modifiés.

  • Équilibrage de charge pour plus de fiabilité. Par exemple, les instances d'un service peuvent être déployées sur Compute Engine dans plusieurs zones, mais être abonnées à un sujet commun. En cas de défaillance du service dans une zone, les autres utilisateurs peuvent récupérer la charge automatiquement.

Types de services Pub/Sub

Pub/Sub se compose de deux services :

  • Service Pub/Sub : Ce service de messagerie est le choix par défaut pour la plupart des utilisateurs et des applications. Il offre la plus haute fiabilité et le plus grand ensemble d'intégrations, ainsi qu'une gestion automatique de la capacité. Pub/Sub garantit la réplication synchrone de toutes les données d'au moins deux zones et la réplication optimale dans une troisième zone supplémentaire.

  • Service Pub/Sub Lite. Un service de messagerie distinct, mais similaire, conçu à moindre coût. Il offre une fiabilité inférieure à celle de Pub/Sub. Il propose un stockage de sujets zonal ou régional. Les sujets zonaux zonaux ne sont stockés que dans une seule zone. Les sujets Lite régionaux répliquent les données dans une deuxième zone de manière asynchrone. En outre, Pub/Sub Lite nécessite de préprovisionner et de gérer la capacité de stockage et de débit. N'envisagez d'utiliser Pub/Sub Lite que pour les applications pour lesquelles un faible coût justifie un travail supplémentaire et réduit la fiabilité.

Pour en savoir plus sur les différences entre Pub/Sub et Pub/Sub Lite, consultez la page Choisir Pub/Sub ou Pub/Sub Lite.

Comparer Pub/Sub à d'autres technologies de messagerie

Pub/Sub associe l'évolutivité horizontale d'Apache Kafka et de Pulsar aux fonctionnalités des middlewares de messagerie traditionnels, comme Apache ActiveMQ et RabbitMQ. Exemples de files d'attente de lettres mortes et de filtres.

Une autre fonctionnalité adoptée par Pub/Sub à partir d'un middleware de messagerie est le parallélisme par message, plutôt que la messagerie basée sur des partitions. Pub/Sub loue des messages individuels aux clients abonnés, puis suit le traitement d'un message donné.

En revanche, d'autres systèmes de messagerie horizontalement évolutifs utilisent des partitions pour le scaling horizontal. Cela oblige les abonnés à traiter les messages dans chaque partition dans l'ordre et limite le nombre de clients simultanés au nombre de partitions. Le traitement par message maximise le parallélisme des applications d'abonnés et assure l'indépendance des éditeurs/abonnés.

Comparer les communications de service à service et de client à client

Pub/Sub est destiné à la communication de service à service plutôt qu'à la communication avec des utilisateurs finaux ou des clients IoT. D'autres modèles sont mieux adaptés aux autres produits :

Vous pouvez utiliser une combinaison de ces services pour créer des clients -> services -> modèles de base de données. Par exemple, consultez le tutoriel Diffuser des messages Pub/Sub via WebSockets.

Intégrations

Pub/Sub offre de nombreuses intégrations à d'autres produits Google Cloud pour créer un système de messagerie complet :

  • Traitement par flux et intégration des données. Cette solution est compatible avec Dataflow, y compris les modèles Dataflow et SQL, qui permettent le traitement et l'intégration de données dans BigQuery et des lacs de données sur Cloud Storage. Des modèles Dataflow permettant de déplacer des données de Pub/Sub vers Cloud Storage, BigQuery et d'autres produits sont disponibles dans les interfaces utilisateur Pub/Sub et Dataflow de la console Google Cloud. L'intégration avec Apache Spark, en particulier lorsqu'elle est gérée avec Dataproc, est également disponible. La composition visuelle des pipelines d'intégration et de traitement s'exécutant sur Spark + Dataproc peut être effectuée avec Data Fusion.
  • Surveillance, alertes et journalisation. Compatible avec les produits Monitoring et Logging.
  • Authentification et IAM. Pub/Sub repose sur une authentification OAuth standard utilisée par d'autres produits Google Cloud et est compatible avec des fonctionnalités IAM précises, ce qui permet de contrôler les accès à des ressources individuelles.
  • API. Pub/Sub utilise les technologies standards des API de service gRPC et REST ainsi que des bibliothèques clientes pour plusieurs langages.
  • Déclencheurs, notifications et webhooks Pub/Sub propose une distribution push des messages sous forme de requêtes HTTP POST aux webhooks. Vous pouvez mettre en œuvre l'automatisation des workflows à l'aide de Cloud Functions ou d'autres produits sans serveur.
  • Orchestration. Pub/Sub peut être intégré de manière déclarative dans des workflows sans serveur à plusieurs étapes. Le big data et l'orchestration analytique sont souvent réalisés avec Cloud Composer, qui est compatible avec les déclencheurs Pub/Sub. Vous pouvez également intégrer Pub/Sub à Application Integration (Preview) qui est une solution Integration Platform en tant que service (iPaaS). Application Integration fournit un déclencheur Pub/Sub permettant de déclencher ou de démarrer des intégrations.
  • Connecteurs d'intégration.(Aperçu) Ces connecteurs vous permettent de vous connecter à diverses sources de données. Avec les connecteurs, les services Google Cloud et les applications métier tierces sont exposés à vos intégrations via une interface standard transparente. Pour Pub/Sub, vous pouvez créer une connexion Pub/Sub à utiliser dans vos intégrations.

Concepts fondamentaux

  • Sujet. Ressource nommée à laquelle les éditeurs envoient des messages.
  • Abonnement. Ressource nommée représentant le flux de messages d'un sujet spécifique à distribuer dans l'application d'abonnement. Pour plus de détails sur les abonnements et la sémantique de distribution des messages, consultez le Guide pour les abonnés.
  • Message. La combinaison des données et des attributs (facultatifs) qu'un éditeur envoie à un sujet et qui est finalement remise aux abonnés.
  • Attribut de message. Paire clé/valeur qu'un éditeur peut définir pour un message. Par exemple, la clé iana.org/language_tag et la valeur en pourraient être ajoutées aux messages pour les marquer comme lisibles par un abonné anglophone.
  • Éditeur. Application qui crée et envoie des messages sur un ou plusieurs sujets.
  • Abonné. Application avec abonnement à un ou plusieurs sujets pour recevoir des messages.
  • Confirmation (ou "confirmation"). Signal envoyé par un abonné à Pub/Sub après la réception d'un message. Les messages confirmés sont supprimés de la file d'attente des messages d'abonnement.
  • Tirez et tirez Les deux modes de distribution des messages. Un abonné reçoit des messages soit par Pub/Sub, en les transmettant au point de terminaison choisi par l'abonné, soit par l'abonné qui les extrait du service.

Les relations éditeur-abonné peuvent être de type un à plusieurs (distribution ramifiée), plusieurs à un (distribution unique) et plusieurs à plusieurs, comme le montre le schéma suivant :

Relations éditeur-abonné

Le diagramme suivant illustre la façon dont un message passe d'un éditeur à un abonné. Pour la distribution push, l'accusé de réception est implicite dans la réponse à la requête push, tandis que pour la distribution pull, il nécessite un RPC distinct.

Cycle de vie des messages

Étapes suivantes