Cette page explique comment recevoir et confirmer des messages à l'aide de la sémantique de type "exactement une fois". Seul le type d'abonnement pull permet la distribution de type "exactement une fois", y compris les abonnés qui utilisent l'API StreamingPull.
Les abonnements push et export ne sont pas compatibles avec la distribution de type "exactement une fois".
Versions recommandées des bibliothèques clientes
- Pour des performances optimales, utilisez la dernière version de la bibliothèque cliente, Python v2.13.6 ou version ultérieure, Java v1.120.11 ou version ultérieure, PHP v1.39.0 ou version ultérieure, C# v3.2.0 ou version ultérieure, C++ v2.1.0 ou version ultérieure{/1.} ou version ultérieure.
Diffusion de type "exactement une fois"
Pub/Sub permet la distribution de type "exactement une fois" dans une région cloud, en fonction d'un ID de message unique défini par Pub/Sub.
Lorsque la fonctionnalité est activée, Pub/Sub fournit les éléments suivants:
Aucune nouvelle livraison ne se produit une fois que le message a bien été confirmé.
Aucune nouvelle distribution n'est effectuée tant qu'un message est en attente. Un message est considéré comme en attente jusqu'à l'expiration du délai de confirmation ou jusqu'à ce qu'il soit confirmé.
En cas de distributions valides multiples, en raison de l'expiration du délai d'accusé de réception ou de l'accusé de réception négatif initié par le client, seul le dernier ID d'accusé de réception peut être utilisé pour confirmer le message. Toutes les requêtes comportant un ID d'accusé de réception précédent échouent.
Nouvelle livraison ou doublon
Il est important de comprendre la différence entre les livraisons prévues et inattendues.
Une nouvelle distribution peut se produire soit en raison d'un accusé de réception négatif à l'initiative du client, soit lorsque le client ne prolonge pas le délai de confirmation du message avant l'expiration du délai de confirmation. Les nouvelles livraisons sont considérées comme valides et le système fonctionne comme prévu.
Pour résoudre les problèmes liés aux nouvelles livraisons, consultez Gérer les doublons et forcer les nouvelles tentatives.
Un doublon se produit lorsqu'un message est renvoyé après un accusé de réception réussi ou avant l'expiration du délai de confirmation.
Un message redistribué conserve le même identifiant entre les tentatives de nouvelle remise.
Les abonnements pour lesquels la distribution de type "exactement une fois" est activée ne reçoivent pas de distributions en double.
Prise en charge de la distribution de type "exactement une fois" dans les bibliothèques clientes
Les bibliothèques clientes compatibles disposent d'une interface d'accusé de réception avec réponse (exemple: Go). Vous pouvez utiliser cette interface pour vérifier si la requête de confirmation a réussi. Si la requête d'accusé de réception aboutit, les clients ne recevront pas de nouvelle livraison. Si la requête d'accusé de réception échoue, les clients peuvent s'attendre à une nouvelle livraison.
Les clients peuvent également utiliser les bibliothèques clientes compatibles sans l'interface d'accusé de réception. Toutefois, dans de tels cas, les échecs de confirmation peuvent entraîner une nouvelle distribution silencieuse des messages.
Les bibliothèques clientes compatibles disposent d'interfaces permettant de définir la durée d'extension de bail minimale (par exemple, Go). Vous devez définir la valeur de l'extension de bail minimale sur un nombre élevé pour éviter toute expiration de la confirmation liée au réseau. La valeur maximale est définie sur 600 secondes.
Les valeurs et la plage par défaut des variables liées à la distribution de type "exactement une fois" et les noms des variables peuvent différer d'une bibliothèque cliente à l'autre. Par exemple, dans la bibliothèque cliente Java, les variables suivantes contrôlent la distribution de type "exactement une fois".
Variable | Description | Valeur |
---|---|---|
setEnableExactlyOnceDelivery |
Active ou désactive l'envoi de type "exactement une fois". | vrai ou faux Par défaut=false |
minDurationPerAckExtension |
Durée minimale à utiliser en secondes pour prolonger le délai de confirmation de la modification. | Plage=0 à 600 Par défaut=aucun |
maxDurationPerAckExtension |
Délai maximal, en secondes, à utiliser pour prolonger le délai de confirmation de la modification. | Plage=0 à 600 Par défaut=aucun |
Dans le cas d'une distribution de type "exactement une fois", la requête modifyAckDeadline
ou acknowledgment
envoyée à Pub/Sub échoue lorsque l'ID d'accusé de réception a déjà expiré. Dans ce cas, le service considère l'ID d'accusé de réception expiré comme non valide, car une distribution plus récente peut déjà être en cours. Cette option est conçue pour une distribution de type "exactement une fois". Vous voyez ensuite que les requêtes acknowledgment
et ModifyAckDeadline
renvoient une réponse INVALID_ARGUMENT
. Lorsque la distribution de type "exactement une fois" est désactivée, ces requêtes renvoient OK
en cas d'ID d'accusé de réception arrivés à expiration.
Pour vous assurer que les requêtes acknowledgment
et ModifyAckDeadline
disposent d'ID d'accusé de réception valides, envisagez de définir la valeur de minDurationPerAckExtension
sur un nombre élevé.
Créer des abonnements avec distribution de type "exactement une fois"
Vous pouvez créer un abonnement avec distribution de type "exactement une fois" à l'aide de la console Google Cloud, de Google Cloud CLI, de la bibliothèque cliente ou de l'API Pub/Sub.
Abonnement pull
Console
Pour créer un abonnement pull avec une distribution de type "exactement une fois", procédez comme suit:
Dans la console Google Cloud, accédez à la page Abonnements.
Cliquez sur Créer un abonnement.
Saisissez l'ID de l'abonnement.
Choisissez ou créez un sujet dans le menu déroulant.
L'abonnement reçoit les messages du sujet.
Dans la section Distribution exactement une fois, sélectionnez Activer la distribution de type "exactement une fois".
Cliquez sur Créer.
gcloud
Pour créer un abonnement pull avec une distribution de type "exactement une fois", utilisez la commande gcloud pubsub subscriptions create
avec l'option --enable-exactly-once-delivery
:
gcloud pubsub subscriptions create SUBSCRIPTION_ID \ --topic=TOPIC_ID \ --enable-exactly-once-delivery
Remplacez les éléments suivants :
- SUBSCRIPTION_ID : ID de l'abonnement à créer
- TOPIC_ID : ID du sujet à associer à l'abonnement
REST
Pour créer un abonnement avec distribution de type "exactement une fois", utilisez la méthode projects.subscriptions.create
.
PUT https://pubsub.googleapis.com/v1/projects/PROJECT_ID/subscriptions/SUBSCRIPTION_ID Authorization: Bearer $(gcloud auth print-access-token)
Remplacez les éléments suivants :
- PROJECT_ID : ID du projet dans lequel créer l'abonnement
- SUBSCRIPTION_ID : ID de l'abonnement à créer
Pour créer un abonnement pull avec une distribution de type "exactement une fois", spécifiez ce qui suit dans le corps de la requête:
{ "topic": "projects/PROJECT_ID/topics/TOPIC_ID", "enableExactlyOnceDelivery": true, }
Remplacez les éléments suivants :
- PROJECT_ID : ID du projet contenant le sujet.
- TOPIC_ID : ID du sujet à associer à l'abonnement
C++
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage C++ qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour C++.
C#
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage C# qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour C#.
Go
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Go qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour Go.
Java
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Java qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour Java.
Python
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Python qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour Python.
Node.js
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Node.js qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour Node.js.
Node.js
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Node.js qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour Node.js.
Ruby
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage Ruby qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour Ruby.
PHP
Avant d'essayer cet exemple, suivez les instructions d'installation dans le langage PHP qui se trouvent sur la page Démarrage rapide : utiliser des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence sur l'API Pub/Sub pour PHP.
S'abonner avec la distribution du message de type "exactement une fois"
Voici quelques exemples de code permettant de s'abonner avec une distribution de type "exactement une fois" à l'aide de la bibliothèque cliente.
Abonnement pull
Go
Avant d'essayer cet exemple, suivez les instructions de configuration de Go décrites dans le guide de démarrage rapide de Pub/Sub à l'aide des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub Go.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Java
Avant d'essayer cet exemple, suivez les instructions de configuration de Java décrites dans le guide de démarrage rapide de Pub/Sub à l'aide des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub Java.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Node.js
Avant d'essayer cet exemple, suivez les instructions de configuration de Node.js décrites dans le guide de démarrage rapide de Pub/Sub à l'aide des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub Node.js.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
PHP
Avant d'essayer cet exemple, suivez les instructions de configuration de PHP décrites dans le guide de démarrage rapide de Pub/Sub à l'aide des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub PHP.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Python
Avant d'essayer cet exemple, suivez les instructions de configuration de Python décrites dans le guide de démarrage rapide de Pub/Sub à l'aide des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub Python.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Ruby
Avant d'essayer cet exemple, suivez les instructions de configuration de Ruby décrites dans le guide de démarrage rapide de Pub/Sub à l'aide des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub Ruby.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
C++
Avant d'essayer cet exemple, suivez les instructions de configuration de C++ décrites dans le guide de démarrage rapide de Pub/Sub à l'aide des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub C++.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
C#
Avant d'essayer cet exemple, suivez les instructions de configuration de C# décrites dans le guide de démarrage rapide de Pub/Sub à l'aide des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub C#.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Node.js (TypeScript)
Avant d'essayer cet exemple, suivez les instructions de configuration pour Node.js du guide de démarrage rapide de Pub/Sub sur l'utilisation des bibliothèques clientes. Pour en savoir plus, consultez la documentation de référence de l'API Pub/Sub pour Node.js.
Pour vous authentifier auprès de Pub/Sub, configurez les Identifiants par défaut de l'application. Pour en savoir plus, consultez Configurer l'authentification pour un environnement de développement local.
Surveiller les abonnements de distribution de type "exactement une fois"
La métrique subscription/exactly_once_warning_count
enregistre le nombre d'événements pouvant entraîner de possibles nouvelles livraisons (valides ou en double). Cette métrique compte le nombre de fois où Pub/Sub ne parvient pas à traiter les requêtes associées aux ID d'accusé de réception (requête ModifyAckDeadline
ou acknowledgment
). Les causes de l'échec peuvent être liées au serveur ou au client. Par exemple, si la couche de persistance utilisée pour gérer les informations de distribution de type "exactement une fois" n'est pas disponible, il s'agit d'un événement basé sur le serveur. Si le client tente d'accuser réception d'un message avec un ID d'accusé de réception non valide, il s'agit d'un événement basé sur le client.
Comprendre la métrique
subscription/exactly_once_warning_count
capture les événements qui peuvent ou non entraîner de nouvelles livraisons et qui peuvent comporter du bruit en fonction du comportement du client. Par exemple, les requêtes acknowledgment
ou ModifyAckDeadline
répétées comportant des ID d'accusé de réception non valides incrémentent la métrique de façon répétée.
Les métriques suivantes sont également utiles pour comprendre le comportement du client:
La métrique
subscription/expired_ack_deadlines_count
indique le nombre d'expirations d'ID d'accusé de réception. Les expirations d'ID d'accusé de réception peuvent entraîner l'échec des requêtesModifyAckDeadline
etacknowledgment
.La métrique
service.serviceruntime.googleapis.com/api/request_count
peut être utilisée pour capturer les échecs des requêtesModifyAckDeadline
ouacknowledgment
lorsque celles-ci atteignent Google Cloud, mais n'atteignent pas Pub/Sub. Il existe des défaillances que cette métrique ne capture pas, par exemple lorsque les clients sont déconnectés de Google Cloud.
Dans la plupart des cas d'échec pouvant faire l'objet de nouvelles tentatives, les bibliothèques clientes compatibles retentent automatiquement la requête.
Quotas
Les abonnements de type "exactement une fois" sont soumis à des exigences de quota supplémentaires. Ces quotas sont appliqués aux éléments suivants:
- Nombre de messages consommés par les abonnements pour lesquels la distribution de type "exactement une fois" est activée par région.
- Nombre de messages confirmés ou dont le délai est prolongé lors de l'utilisation d'abonnements avec la distribution de type "exactement une fois" activée par région.
Pour en savoir plus sur ces quotas, consultez le tableau de la rubrique Quotas.
Livraison "exactement une fois" et abonnements commandés
Pub/Sub permet la distribution "exactement une fois" avec la livraison commandée.
Lorsque vous utilisez la commande avec distribution "exactement une fois", Pub/Sub s'attend à ce que les confirmations soient dans l'ordre. Si les accusés de réception sont dans le désordre, le service fait échouer les requêtes en générant des erreurs temporaires. Si le délai de confirmation expire avant un accusé de réception dans l'ordre de la distribution, le client reçoit une nouvelle remise du message. De ce fait, lorsque vous utilisez le tri avec une distribution de type "exactement une fois", le débit du client est limité à une commande de milliers de messages par seconde.
Distribution de type "exactement une fois" et abonnements push
Pub/Sub n'accepte la distribution de type "exactement une fois" qu'avec les abonnements pull.
Les clients qui consomment les messages des abonnements push accusent réception des messages en répondant aux requêtes push avec une réponse positive. Toutefois, les clients ne savent pas si l'abonnement Pub/Sub a reçu la réponse et l'a traitée. Ceci est différent des abonnements pull, pour lesquels les requêtes d'accusé de réception sont lancées par les clients et l'abonnement Pub/Sub répond si la requête a été traitée correctement. Pour cette raison, la sémantique de distribution de type "exactement une fois" ne s'aligne pas bien avec les abonnements push.
Bon à savoir
Si le délai d'accusé de réception n'est pas spécifié au moment de CreateSubscription, le délai d'accusé de réception par défaut est de 60 secondes pour les abonnements pour lesquels la distribution est activée "exactement une fois".
Des délais d'accusé de réception par défaut plus longs permettent d'éviter la nouvelle livraison causée par des événements réseau. Les bibliothèques clientes compatibles n'utilisent pas le délai de confirmation d'abonnement par défaut.
Les abonnements de type "exactement une fois" présentent une latence publication/abonnement nettement supérieure à celle des abonnements standards.
Si vous avez besoin d'un débit élevé, vos clients de diffusion de type "exactement une fois" doivent également utiliser la méthode pull en flux continu.
Un abonnement peut recevoir plusieurs copies du même message en raison de doublons côté publication, même lorsque la distribution "exactement une fois" est activée. Les doublons côté publication peuvent être dus à plusieurs tentatives de publication uniques par le client de publication ou le service Pub/Sub. Plusieurs publications uniques par le client éditeur, entre les tentatives, entraînent de nouvelles livraisons avec des ID de message différents. Plusieurs publications uniques par le service Pub/Sub entraînent des renvois de messages avec les mêmes ID de message pour répondre à une requête de publication client.
Vous pouvez effectuer de nouvelles tentatives en cas d'échec dans
subscription/exactly_once_warning_count
. Les bibliothèques clientes compatibles relancent automatiquement ces tentatives. Toutefois, les échecs liés à des ID d'accusé de réception non valides ne peuvent pas être relancés.