Ce document suppose que vous connaissez déjà le processus d'abonnement à un sujet Pub/Sub et de réception de messages dans votre client abonné.
Si vous débutez avec Pub/Sub, consultez l'un des guides de démarrage rapide et découvrez comment exécuter Pub/Sub à l'aide de la console, de la Google Cloud CLI ou des bibliothèques clientes.
Choisir le bon abonnement
Pub/Sub propose des abonnements standards, tels que les abonnements push et pull. En plus des abonnements standards, Pub/Sub propose également des abonnements d'exportation qui vous permettent de stocker des messages directement dans une ressourceGoogle Cloud , sans passer par Dataflow. Par exemple, les abonnements BigQuery stockent les messages dans une table BigQuery.
Les abonnements push sont recommandés dans les scénarios suivants :
Vous ne pouvez pas inclure dans votre application d'abonné du code qui importe la bibliothèque cliente en tant que dépendance.
Le client abonné ne peut pas envoyer de requêtes sortantes.
Vous souhaitez utiliser la même instance pour traiter les messages de différents sujets et abonnements, où le client abonné ne connaît pas la liste des abonnements.
Pour les cas généraux, nous vous recommandons d'utiliser la bibliothèque cliente de haut niveau. Si vous utilisez l'extraction unaire, ne définissez pas returnImmediately sur true. La définir sur true a un impact négatif sur les performances d'extraction.
Le champ returnImmediately est désormais obsolète.
Pour comparer tous les types d'abonnement et choisir celui qui correspond le mieux aux besoins de votre entreprise, consultez le tableau de comparaison des abonnements Pub/Sub.
Pour en savoir plus sur les avantages d'un abonnement d'exportation, consultez Quand utiliser un abonnement d'exportation.
Traiter les messages avant d'en accuser réception
Par défaut, Pub/Sub supprime un message d'un abonnement une fois qu'il a été confirmé. Si vous ne traitez pas un message avant d'envoyer un accusé de réception et que le traitement échoue, le service ne renvoie pas le message. L'exception concerne les cas où vous avez configuré la conservation des messages confirmés ou la conservation des sujets, et que vous effectuez une opération de recherche.
Si vous avez des abonnés à latence élevée, vous devrez peut-être définir des valeurs personnalisées pour le contrôle de flux et la gestion des baux.
Conserver les ID de message
Pour faciliter le dépannage, les éditeurs et les abonnés doivent conserver les ID des messages publiés. Vous pouvez stocker l'ID de chaque message publié ou activer la journalisation des ID de message si nécessaire. La conservation des ID de message facilite la résolution des problèmes de messages en double, de nouvelles livraisons, de perte de données et d'autres problèmes courants. Pour en savoir plus, consultez Gérer les doublons.
Configurer le contrôle de flux des abonnés pour les pics de trafic temporaires
Le contrôle de flux côté abonné vous permet d'éviter que les abonnés ne soient surchargés par des pics de trafic. Cela peut laisser le temps aux mécanismes d'autoscaling de répondre à une augmentation de la charge ou de répartir le traitement de la charge sur une période plus longue. La première méthode réduit la latence, tandis que la seconde réduit les coûts.
Pour configurer le contrôle de flux, vous devez définir des valeurs appropriées pour maximum outstanding messages et total outstanding message bytes. Les valeurs par défaut de ces variables de contrôle de flux et les noms des variables peuvent différer d'une bibliothèque cliente à l'autre.
Nombre maximal de messages en attente définit le nombre maximal de messages distribués au client pour lesquels Pub/Sub n'a pas reçu d'accusés de réception ou d'accusés de réception négatifs.
Nombre total d'octets de messages en attente définit la taille totale maximale des messages envoyés au client pour lesquels Pub/Sub n'a pas reçu d'accusés de réception ou d'accusés de réception négatifs.
Si la limite de l'une de ces options est dépassée, le client abonné n'extrait plus de messages. Ce comportement se poursuit jusqu'à ce que les messages déjà extraits soient confirmés ou non. De cette façon, vous pouvez trouver un compromis entre le débit et le coût associé à l'exécution d'un plus grand nombre d'abonnés.
Gérer les diffusions en double
Par défaut, Pub/Sub assure une distribution de type "au moins une fois" des messages aux abonnés. Cela signifie que les messages peuvent être distribués plusieurs fois, même s'ils ont été confirmés. Les sections suivantes expliquent comment gérer les scénarios de nouvelle livraison courants.
Nouvelle livraison cohérente de nombreux messages
Si vous constatez que de nombreux messages sont toujours renvoyés, cela signifie que vos abonnés sont surchargés ou qu'ils ne confirment pas les messages avant l'expiration du délai.
Si vous utilisez un abonnement pull, vous devrez peut-être définir des valeurs personnalisées pour les valeurs de contrôle de flux ou augmenter les périodes de prolongation de bail à l'aide de la gestion des baux.
Si vous utilisez des abonnements push, vous devrez peut-être augmenter le paramètre de délai d'accusé de réception. Vous pouvez également suivre les bonnes pratiques pour maintenir un abonnement sain.
Nouvelle livraison occasionnelle de messages
Lorsque vous voyez des messages être livrés à nouveau avant l'expiration du délai d'accusé de réception ou après que les messages ont été confirmés en quelques secondes, Pub/Sub se comporte comme prévu. Vous ne devriez pas voir ces pics de nouvelles livraisons fréquemment, mais lorsqu'ils se produisent, ils sont susceptibles de se produire sur plusieurs messages simultanément. Votre système doit être conçu pour tolérer ces doublons occasionnels.
Nouvelle livraison répétée de quelques messages
Si vous constatez qu'un petit nombre de messages sont distribués plusieurs fois, vérifiez d'abord que vous en accusez réception. Si ce n'est pas le cas, déterminez pourquoi votre abonné ne gère pas correctement les messages. Vous pouvez configurer une file d'attente de lettres mortes pour empêcher toute nouvelle distribution. Si vous accusez réception du message, il est possible que Pub/Sub fonctionne toujours comme prévu. Bien que cela soit très rare, il est possible qu'un petit nombre de messages soient distribués plusieurs fois en cas de perturbations internes du réseau ou du matériel. Dans ce cas, le service tente de s'autoréparer, mais l'activation des solutions peut prendre plusieurs minutes.
Votre système doit tolérer les nouvelles livraisons. Vous pouvez réduire leur probabilité en vous assurant de traiter et d'accuser réception des messages le plus rapidement possible.
Si votre application ne peut tolérer aucun doublon, vous pouvez activer la distribution de type "exactement une fois". N'oubliez pas que cette fonctionnalité n'est disponible que pour les abonnements pull et qu'elle entraîne également une latence de publication-abonnement plus élevée. Avant d'activer cette fonctionnalité, déterminez si le compromis d'une latence plus élevée est acceptable pour votre cas d'utilisation.
Bonnes pratiques pour la messagerie ordonnée dans l'abonnement
Si vous utilisez le séquencement des messages, assurez-vous de respecter les points suivants :
Choisissez entre les abonnements StreamingPull ou Pull. Pour un abonnement push, Pub/Sub n'accepte qu'un seul message en attente pour chaque clé de tri à la fois. Dans un tel scénario, l'envoi de requêtes push parallèles reviendrait à envoyer simultanément plusieurs lots de messages pour la même clé de tri aux abonnés pull. Par conséquent, les abonnements push ne sont pas recommandés pour les sujets où plusieurs messages sont fréquemment publiés avec la même clé de tri ou lorsque la latence est extrêmement importante.
Activez le tri des messages dans l'abonnement. Côté éditeur, si vous envoyez des messages avec une clé de tri et dans la même région, vous pouvez configurer les abonnés pour qu'ils reçoivent ces messages dans l'ordre. Du côté de l'abonné, activez la propriété de tri des messages uniquement pour les abonnements pour lesquels vous souhaitez recevoir des messages triés. En fonction de l'état de la propriété, chaque abonnement associé au sujet peut déterminer s'il a besoin d'une distribution ordonnée sans que cela n'ait d'impact sur les autres.
Accusez réception des messages dans l'ordre. Lorsque vous utilisez la distribution ordonnée, les accusés de réception des messages ultérieurs ne sont pas traités tant que les accusés de réception des messages antérieurs ne sont pas traités par clé de tri. Par exemple, si vous avez les messages 1, 2 et 3 avec la même clé de tri, que vous les recevez tous et que vous n'accusez réception que du message 3, le service ne considère pas le message 3 comme confirmé tant que les messages 1 et 2 ne sont pas également confirmés. Si les accusés de réception des messages 1 et 2 ne sont jamais reçus, les messages 1, 2 et 3 sont tous renvoyés.
Récapitulatif des bonnes pratiques
Le tableau suivant récapitule les bonnes pratiques recommandées dans ce document :
| Sujet | Tâche |
|---|---|
| Choisir un type d'abonnement | Choisissez le type d'abonnement adapté aux besoins de votre entreprise. Si votre abonnement le permet, utilisez également la bibliothèque cliente de haut niveau. |
| Relire un message confirmé | Traitez un message avant d'en accuser réception. Vous pouvez également configurer une opération de recherche afin de ne pas perdre les messages confirmés. |
| Contrôle de flux | Configurez le contrôle de flux dans vos paramètres d'abonné pour vous assurer que les abonnés ne sont pas surchargés avant que l'autoscaling ne se déclenche ou que le temps ne s'écoule. |
| Gérer les distributions en double et conserver les ID de message | Conservez ou activez la journalisation de l'messageId reçu pour simplifier le dépannage des doublons, des nouvelles livraisons et des messages manquants. |
| Trier des messages | Lorsque vous utilisez la messagerie ordonnée, choisissez StreamingPull ou Pull, activez l'ordonnancement des messages dans l'abonnement et accusez réception des messages dans l'ordre. |