Présentation des files d'attente Spanner

Les files d'attente Spanner fournissent une solution de messagerie transactionnelle pour vous aider à gérer le travail asynchrone. Cette fonctionnalité associe cette capacité à l'évolutivité et à la fiabilité de Spanner, ce qui vous permet de créer des applications événementielles. Les files d'attente Spanner utilisent un modèle pull pour la consommation des messages, en exposant une interface SQL permettant aux destinataires de demander et de recevoir des messages.

Choisir entre les files d'attente et les flux de modifications Spanner

La comparaison suivante vous aidera à choisir le mécanisme approprié pour la propagation des données et le traitement asynchrone.

Files d'attente Spanner

Application idéale

  • Notifications d'événements transactionnels
  • Exécution de tâches planifiées
  • Logique d'accusé de réception par message

Caractéristiques principales

  • Petites charges utiles de messages définies par l'utilisateur
  • Modèle pull pour la consommation de messages
  • Évolue avec la puissance de calcul de l'instance Spanner

Flux de modifications Spanner

Application idéale

  • Réplication de données à haut débit
  • Synchroniser les caches ou les index en aval
  • Journalisation d'audit de chaque modification de la base de données

Caractéristiques principales

  • Capture tous les fragments d'enregistrement (jusqu'à 10 Mo)
  • Streaming en mode Pull à l'aide de jetons de partition
  • Inclut les pulsations et la création de points de contrôle

Principaux avantages

Les files d'attente Spanner offrent plusieurs avantages :

  • Intégrée : la messagerie est intégrée à la base de données. Cela élimine le besoin de provisionner, de gérer et d'exfiltrer des données vers une infrastructure de messagerie distincte, ce qui simplifie l'architecture des applications et réduit les coûts globaux.
  • Transactionnel : vous pouvez envoyer et accuser réception des messages de manière atomique dans une transaction Spanner, en même temps que d'autres écritures de base de données. Les messages mis en file d'attente sont annulés et ne sont pas disponibles pour la distribution si la transaction échoue.
  • Durables : les messages qui ne peuvent pas être distribués sont stockés dans la base de données. Spanner tente en permanence de distribuer le message avec un intervalle exponentiel entre les tentatives jusqu'à ce que sa réception soit explicitement confirmée ou qu'il soit supprimé.
  • Interrogeables : les messages sont basés sur les mêmes primitives que les tables Spanner et sont stockés sous forme de lignes. Vous pouvez les interroger, les joindre ou les filtrer comme des tables standards.
  • Évolutivité : le traitement des messages est aussi évolutif que le reste de votre base de données, car il est basé sur la même évolutivité que les tables Spanner.
  • Fiabilité : les files d'attente Spanner héritent de toutes les primitives de haute disponibilité de Spanner, ce qui rend l'envoi et le traitement des messages tolérants aux pannes et résilients aux défaillances zonales ou régionales.
  • Planifiable : les messages peuvent être planifiés pour une livraison ultérieure, ce qui vous permet de différer l'exécution d'une tâche à un code temporel ultérieur spécifique.
  • Atomique : l'envoi de messages (API INSERT ou de mutation) et l'accusé de réception (API DELETE ou de mutation) s'exécutent de manière atomique dans les transactions, ce qui garantit la cohérence avec l'état de la base de données.
  • Extensibilité : les baux de messages peuvent être étendus pour prendre en charge des temps de traitement extrêmement longs en combinant les mécanismes de livraison future et de bail manuel.

Cas d'utilisation

Les files d'attente Spanner sont utiles pour orchestrer les tâches différées au sein d'une transaction. Voici quelques exemples courants :

  • Différer les tâches gourmandes en ressources de calcul : un site Web de partage de photos peut avoir besoin d'effectuer un traitement d'image intensif lorsqu'une nouvelle photo est importée. La transaction qui écrit les nouvelles métadonnées de la photo peut écrire simultanément un message dans la file d'attente. Un récepteur de file d'attente récupère ensuite le message, effectue le traitement et met à jour les métadonnées de manière transactionnelle.
  • Différer les mises à jour transactionnelles importantes : dans une application d'agenda, inviter un grand groupe à une réunion dans une seule transaction peut entraîner des conflits de verrouillage et des latences de queue. Au lieu de cela, la transaction qui crée l'entrée d'agenda peut ajouter une entrée de file d'attente pour chaque invité, ce qui permet à un destinataire d'envoyer les invitations individuellement.
  • Planification de tâches dans le futur : une entreprise de logiciel en tant que service (SaaS) proposant un essai sans frais de 30 jours peut provisionner les ressources de l'utilisateur et mettre simultanément en file d'attente un message qui doit être envoyé dans 30 jours. Un nœud de calcul reçoit ensuite le message et exécute la logique d'expiration de l'essai.
  • Différer le travail vers des systèmes externes : après l'enregistrement d'un utilisateur, une application peut avoir besoin d'envoyer un e-mail de bienvenue uniquement si l'enregistrement dans la base de données réussit. La transaction d'enregistrement peut ajouter une entrée à une file d'attente, ce qui permet à un worker d'appeler une API de messagerie externe ultérieurement.
  • Orchestration de pipelines en plusieurs étapes : dans un système de gestion des commandes, le traitement d'une commande implique plusieurs étapes qui peuvent échouer indépendamment. En représentant chaque étape sous la forme d'un message de file d'attente, le système peut enregistrer l'état du pipeline et reprendre à partir du point d'échec.

Workflow

Un workflow type pour les files d'attente Spanner comprend les étapes suivantes :

  • Créer une file d'attente : définissez une file d'attente à l'aide du LDD, comme pour une table. Il doit inclure une colonne Payload (payload dans PostgreSQL) et une clé primaire.
  • Envoyer des messages : mettez en file d'attente des messages à l'aide du LMD standard (INSERT) ou des API de mutation, de manière transactionnelle avec d'autres opérations de base de données.
  • Recevoir des messages : utilisez l'API ExecuteStreamingSQL pour appeler une fonction de valeur de table (TVF) nommée RECEIVE_QUEUE_NAME(). Cette fonction diffuse des messages à votre client sous la forme d'une requête de longue durée.
  • Traitez les messages : consommez les messages reçus du TVF avec la logique de votre application.
  • Accuser réception des messages : supprimez les messages de la file d'attente à l'aide des API LMD (DELETE) ou de mutation (telles que ack). Cette opération est généralement effectuée une fois le traitement terminé, dans une transaction.
  • Gérer les baux : gérez les baux de messages pour vous assurer que les files d'attente Spanner ne redistribuent pas les messages en cas de délai d'expiration du bail. La méthode la plus courante consiste à utiliser la TVF RENEWLEASE_QUEUE_NAME().

Gardez également à l'esprit les comportements de base suivants des files d'attente Spanner :

  • Distribution "au moins une fois" : comme la plupart des systèmes de files d'attente basés sur le cloud, Spanner promet une distribution "au moins une fois". Les nouvelles livraisons peuvent être évitées en prolongeant les baux.
  • Accusé de réception "au plus une fois" : l'accusé de réception d'un message se faisant par le biais d'une transaction, la sémantique ACID de Spanner garantit qu'un message n'est accusé qu'une seule fois. Suivez les méthodes décrites sur la page Traitement de type "exactement une fois" et accusé de réception de type "au maximum une fois" pour implémenter correctement l'accusé de réception de type "au maximum une fois".

Limites

Les files d'attente Spanner présentent les limites suivantes :

  • Nombre maximal de récepteurs : le nombre de requêtes de réception actives avec les mêmes arguments est limité à 1 000 par file d'attente.
  • Limite de quota pour les TVF de réception simultanée : la limite de quota est de 2 000 TVF de réception simultanée par projet et par région. Pour augmenter la limite de quota, remplissez le formulaire Demander une augmentation de quota pour votre projet Cloud Spanner.
  • Fractionnement manuel : l'API AddSplits n'est pas compatible avec les files d'attente. La répartition de la charge de travail repose entièrement sur la répartition basée sur la charge. Il est recommandé d'entrelacer la file d'attente dans un tableau afin que les utilisateurs puissent y ajouter des points de fractionnement.
  • Conformité du partitionnement géographique : les files d'attente partitionnées par zone géographique ne sont pas conformes à la résidence des données après l'exécution d'une opération DROP PARTITION.
  • Limites du nombre de files d'attente : les instances sont limitées à 100 files d'attente pour les instances comportant au moins un nœud. La limite est réduite proportionnellement pour les instances granulaires (par exemple, les instances avec 200 unités de traitement sont limitées à 20 files d'attente).
  • Suppression et recréation d'une file d'attente : la suppression et la recréation d'une file d'attente portant le même nom ne sont pas entièrement prises en charge. Le RECEIVE TVF de la file d'attente peut prendre du temps à se "réinitialiser" avant que les messages puissent être reçus à nouveau sous le même nom.
  • Nommage des colonnes PostgreSQL : Spanner expose les colonnes deliver_time et DeliverTime pour le délai de remise d'un message. Nous vous recommandons d'utiliser la colonne deliver_time pour vous aligner sur les conventions de nommage PostgreSQL standards, et parce que la colonne DeliverTime sera masquée du schéma d'informations dans une prochaine version.
  • Schéma nommé : les files d'attente ne peuvent pas être créées dans les schémas nommés.

Étapes suivantes