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 revenir en arrière et de relire des 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
Lorsqu'un message est envoyé à un abonné, celui-ci doit accuser réception du message.
Si un message est envoyé pour être distribué et qu'un abonné ne l'a pas encore reçu, il est considéré comme étant en attente.
Pub/Sub tente à plusieurs reprises de distribuer un message qui n'a pas encore été confirmé. Cependant, Pub/Sub tente de ne pas distribuer de message en attente à 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. Passé ce délai, le message n'est plus considéré comme en attente et Pub/Sub tente de le redistribuer.
Types d'abonnements
Lorsque vous créez un abonnement, vous devez spécifier le type de distribution des messages. Pub/Sub propose trois types de distribution de messages correspondant aux trois types d'abonnements suivants. Chaque type d'abonnement est décrit brièvement dans les sections suivantes de ce document.
- Abonnement pull
- Abonnement push
- Abonnement BigQuery
Vous pouvez modifier le type d'abonnement à tout moment.
Abonnement pull
Pour un abonnement pull, votre client abonné envoie des requêtes à un serveur Pub/Sub pour récupérer les messages. Le client abonné utilise l'API REST Pull, l'API RPC PullRequest, l'API REST StreamingPullRequest ou l'API RPC StreamingPullRequest. La plupart des clients abonnés n'envoient pas ces requêtes directement.
Au lieu de cela, les clients s'appuient 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 manière dont les messages sont extraits, Pub/Sub utilise une bibliothèque gRPC de bas niveau générée automatiquement. Cette bibliothèque permet d'envoyer directement ou en streaming des requêtes pull. Ces requêtes peuvent être synchrones ou asynchrones.
Les deux images suivantes illustrent le workflow entre un client abonné et un abonnement pull.
Le workflow d'extraction se présente comme suit et fait référence à la figure 1:
Le client abonné appelle explicitement la méthode pull, qui demande la distribution des messages. Cette requête correspond à la requête pull indiquée dans l'image.
Le serveur Pub/Sub répond avec zéro ou plusieurs messages et ID d'accusé de réception. Une réponse sans message ou avec une erreur ne signifie pas nécessairement qu'aucun message n'est disponible. Cette réponse correspond à la réponse PullResponse indiquée dans l'image.
Le client abonné appelle explicitement la méthode confirmée. Le client utilise l'ID de confirmation renvoyé pour indiquer que le message est traité et qu'il n'a pas besoin d'être distribué à nouveau. Cette requête est la requête AckRequest, comme illustré dans l'image.
Pour une seule demande d'extraction en flux continu, un client abonné peut renvoyer plusieurs réponses en raison de la connexion ouverte. En revanche, une seule réponse est renvoyée pour chaque demande d'extraction.
Pour en savoir plus sur le fonctionnement d'un abonnement pull et pour consulter des exemples de configuration, consultez la section Abonnements pull.
Abonnement push
Dans le cas d'un abonnement push, un serveur Pub/Sub envoie une requête à votre client abonné pour lui fournir des messages.
L'image suivante montre le workflow entre un client abonné et un abonnement push.
Voici une brève description du workflow qui fait référence à la Figure 3:
Le serveur Pub/Sub envoie chaque message en tant que requête HTTPS au client abonné, sur un point de terminaison préconfiguré. Cette requête est affichée en tant que PushRequest dans l'image.
Le point de terminaison accuse réception du message en renvoyant un code d'état HTTP de réussite. Une réponse négative indique que Pub/Sub doit renvoyer les messages. Cette réponse est affichée en tant que PushResponse dans l'image.
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 d'un abonnement push et pour consulter des exemples de configuration, consultez la section Abonnements push.
Abonnement BigQuery
Un abonnement BigQuery écrit les messages dans une table BigQuery existante dès leur réception. Vous n'avez pas besoin de configurer un client abonné distinct.
Sans le type d'abonnement BigQuery, vous avez besoin d'un abonnement pull ou push et d'un abonné (tel que Dataflow) qui lit les messages et les écrit dans une table BigQuery. La surcharge d'exécution d'une tâche Dataflow n'est pas nécessaire lorsque les messages ne nécessitent aucun traitement supplémentaire avant de les stocker dans une table BigQuery. Vous pouvez utiliser un abonnement BigQuery à la place. Toutefois, un pipeline Dataflow est toujours recommandé pour les systèmes Pub/Sub dans lesquels une transformation des données est requise avant le stockage des données dans une table BigQuery. Pour savoir comment transférer des données de Pub/Sub vers BigQuery avec transformation à l'aide de Dataflow, consultez la page Diffuser des données depuis Pub/Sub vers BigQuery.
L'image suivante montre le workflow entre un abonnement BigQuery et BigQuery.
Voici une brève description du workflow qui fait référence à la Figure 4:
- Pub/Sub utilise l'API d'écriture BigQuery Storage pour envoyer des données à la table BigQuery.
- Les messages sont envoyés par lot à la table BigQuery.
- Une fois l'opération d'écriture terminée, l'API renvoie une réponse "OK".
- Si l'opération d'écriture échoue, le message Pub/Sub lui-même est confirmé. Le message est ensuite renvoyé. Si le message échoue suffisamment de fois et qu'un sujet de lettres mortes est configuré sur l'abonnement, le message est déplacé vers ce sujet.
Pour en savoir plus sur le fonctionnement d'un abonnement BigQuery, consultez la page Abonnements BigQuery.
Choisir votre type d'abonnement
Consultez le tableau suivant qui vous aidera à choisir le système de distribution approprié pour votre application :
| Pull | Push | BigQuery | |
|---|---|---|---|
| Cas d'utilisation |
|
|
|
| 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. Ainsi, les messages de plusieurs abonnements peuvent être envoyés à un seul point de terminaison. | Une table BigQuery. |
| Équilibrage de charge | Plusieurs abonnés peuvent passer des appels pull 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. | Le service Pub/Sub équilibre automatiquement la charge. |
| Configuration | Aucune configuration n'est requise. | Aucune configuration n'est requise pour les applications App Engine du même projet que l'abonné.
La validation des points de terminaison push n'est pas obligatoire dans la console Google Cloud. Endpoints doit être accessible à l'aide de noms DNS et disposer de certificats SSL installés. |
Une table BigQuery doit exister pour l'abonnement au sujet. |
| Contrôle de flux | Le client abonné contrôle la fréquence de diffusion. L'abonné peut modifier de manière dynamique le délai d'accusé de réception, ce qui permet de prolonger arbitrairement le traitement 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. Toutefois, il est possible d'indiquer que le client ne peut pas gérer la charge de messages actuelle en renvoyant une erreur HTTP. | Le serveur Pub/Sub implémente automatiquement un contrôle de flux afin d'optimiser l'écriture des messages dans BigQuery. |
| Efficacité et débit | Atteint un débit élevé avec des ressources de processeur et de bande passante faibles, en permettant une livraison par lots et des accusés de réception, ainsi qu'une consommation massivement parallèle. Peut être inefficace si l'interrogation agressive est utilisée pour réduire le délai de distribution des messages. | Distribue un message par requête et limite le nombre maximal de messages en attente. | L'évolutivité est gérée de manière dynamique par les serveurs Pub/Sub. |
Propriétés d'abonnement par défaut
Par défaut, Pub/Sub offre une distribution de type "au moins une fois" sans garantie de classement sur tous les types d'abonnements. Si les messages ont la même clé de tri et se trouvent dans la même région, vous pouvez également activer le tri des messages. Une fois que vous avez défini la propriété de tri des messages, le service Pub/Sub distribue les messages avec la même clé de tri et dans l'ordre dans lequel le service Pub/Sub les reçoit.
Pub/Sub est également compatible avec la diffusion de type "exactement une fois".
En général, Pub/Sub distribue chaque message une fois et dans l'ordre dans lequel il a été publié. Cependant, les messages peuvent parfois être distribués dans le désordre ou plusieurs fois. Pub/Sub peut renvoyer un message même après qu'une requête d'accusé de réception pour le message a bien été renvoyée. Cette rediffusion peut être causée par des problèmes tels que des redémarrages côté serveur ou des problèmes côté client. Ainsi, bien que cela soit rare, tout message peut être remis à tout moment. Lorsque la distribution est effectuée plusieurs fois, votre abonné doit être idempotent lors du traitement des messages.
Expiration de l'abonnement
Par défaut, les abonnements expirent après 31 jours d'inactivité de l'abonné ou en l'absence de mise à jour. Les connexions ouvertes, les actions pull actives ou push réussies en sont des exemples. Si Pub/Sub détecte une activité d'abonné ou une mise à jour des propriétés de l'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 rendre l'abonnement 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 de nombreux messages non confirmés, un nouvel abonnement portant le même nom ne présenterait 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
- En savoir plus sur les abonnements pull
- En savoir plus sur les abonnements Push
- En savoir plus sur les abonnements BigQuery