Panoramica delle code Spanner

Le code Spanner forniscono messaggi transazionali per aiutarti a gestire il lavoro asincrono. Questa funzionalità combina questa capacità con la scalabilità e l'affidabilità di Spanner, consentendoti di creare applicazioni basate su eventi. Le code Spanner utilizzano un modello pull per il consumo dei messaggi, esponendo un'interfaccia SQL per consentire ai destinatari di richiedere e ricevere messaggi.

Scegliere tra code Spanner e modifiche in tempo reale

Il seguente confronto fornisce indicazioni sulla scelta del meccanismo giusto per la propagazione dei dati e l'elaborazione asincrona.

Code Spanner

Ideale per

  • Notifiche di eventi transazionali
  • Esecuzione del lavoro pianificata per il futuro
  • Logica di riconoscimento per messaggio

Caratteristiche principali

  • Payload dei messaggi piccoli e definiti dall'utente
  • Modello pull per il consumo dei messaggi
  • Scalabile con il calcolo dell'istanza Spanner

Modifiche in tempo reale di Spanner

Ideale per

  • Replica dei dati ad alta velocità effettiva
  • Sincronizzazione di cache o indici downstream
  • Audit logging di ogni modifica al database

Caratteristiche principali

  • Acquisisce tutti i frammenti del record (fino a 10 MB)
  • Streaming basato sul pull utilizzando i token di partizione
  • Include heartbeat e checkpoint

Principali vantaggi

Le code Spanner offrono diversi vantaggi:

  • Integrata:la messaggistica è integrata nel database. In questo modo non è necessario eseguire il provisioning, gestire ed esfiltrare i dati in un'infrastruttura di messaggistica separata, il che semplifica l'architettura dell'applicazione e riduce i costi complessivi.
  • Transazionali:puoi inviare e riconoscere i messaggi in modo atomico all'interno di una transazione Spanner insieme ad altre scritture di database. I messaggi in coda vengono annullati e non sono disponibili per la consegna se la transazione non va a buon fine.
  • Durabili:i messaggi che non possono essere consegnati vengono archiviati nel database. Spanner tenta continuamente la consegna con backoff finché il messaggio non viene riconosciuto o eliminato in modo esplicito.
  • I messaggi interrogabili sono basati sugli stessi primitivi delle tabelle Spanner e vengono archiviati come righe. Puoi eseguire query, unire o filtrare come tabelle standard.
  • Scalabile:creato con la stessa scalabilità delle tabelle Spanner, l'elaborazione dei messaggi viene scalata insieme al resto del database.
  • Affidabili:le code Spanner ereditano tutte le primitive di alta affidabilità di Spanner, rendendo l'invio e l'elaborazione dei messaggi a tolleranza di errore e resilienti agli errori zonali o regionali.
  • Pianificabili:i messaggi possono essere pianificati per la consegna futura, consentendoti di posticipare l'esecuzione dell'attività a un timestamp futuro specifico.
  • Atomico:l'invio di messaggi (API INSERT o di mutazione) e la conferma (API DELETE o di mutazione) vengono eseguiti in modo atomico all'interno delle transazioni, garantendo la coerenza con lo stato del database.
  • Estendibile: i lease dei messaggi possono essere estesi per supportare tempi di elaborazione estremamente lunghi combinando meccanismi di consegna futura e leasing manuale.

Casi d'uso

Le code Spanner sono utili per orchestrare le attività differite all'interno di una transazione. Esempi più comuni:

  • Posticipare il lavoro con un elevato carico di calcolo:un sito web di condivisione di foto potrebbe dover eseguire un'elaborazione intensiva delle immagini quando viene caricata una nuova foto. La transazione che scrive i nuovi metadati della foto può scrivere contemporaneamente un messaggio nella coda. Un ricevitore di coda recupera in un secondo momento il messaggio, esegue l'elaborazione e aggiorna i metadati in modo transazionale.
  • Posticipare gli aggiornamenti transazionali di grandi dimensioni:in un'app di calendario, invitare un gruppo di grandi dimensioni a una riunione in un'unica transazione può causare conflitti di blocco e latenze di coda. Invece, la transazione che crea la voce di calendario può aggiungere una voce della coda per ogni invitato, consentendo a un destinatario di inviare gli inviti singolarmente.
  • Pianificazione di attività future: un'azienda di software as a service (SaaS) che offre una prova senza costi di 30 giorni può eseguire il provisioning delle risorse dell'utente e contemporaneamente mettere in coda un messaggio pianificato per essere consegnato tra 30 giorni. Un worker riceve quindi il messaggio ed esegue la logica di scadenza della prova.
  • Rimandare il lavoro a sistemi esterni: dopo la registrazione di un utente, un'applicazione potrebbe dover inviare un'email di benvenuto solo se la registrazione del database va a buon fine. La transazione di registrazione può aggiungere una voce a una coda, consentendo a un lavoratore di richiamare un'API email esterna in un secondo momento.
  • Orchestrazione di pipeline in più fasi:in un sistema di gestione degli ordini, l'evasione di un ordine prevede più passaggi che potrebbero non riuscire in modo indipendente. Rappresentando ogni passaggio come un messaggio della coda, il sistema può controllare lo stato della pipeline e continuare dal punto in cui si è verificato l'errore.

Workflow

Un workflow tipico per le code Spanner segue questi passaggi:

  • Crea una coda:definisci una coda utilizzando DDL, in modo simile a una tabella. Deve includere una colonna Payload (payload in PostgreSQL) e una chiave primaria.
  • Invio di messaggi:metti in coda i messaggi utilizzando DML standard (INSERT) o API di mutazione, in modo transazionale con altre operazioni di database.
  • Ricevi messaggi:utilizza l'API ExecuteStreamingSQL per chiamare una funzione con valori di tabella (TVF) denominata RECEIVE_QUEUE_NAME(). Questa funzione trasmette i messaggi al client come query a esecuzione prolungata.
  • Elabora messaggi:utilizza i messaggi ricevuti dal TVF con la logica dell'applicazione.
  • Riconoscere i messaggi:rimuovi i messaggi dalla coda utilizzando DML (DELETE) o le API di mutazione (ad esempio ack). Questa operazione viene in genere eseguita al termine dell'elaborazione, all'interno di una transazione.
  • Gestisci lease:gestisci i lease dei messaggi per assicurarti che le code Spanner non inviino nuovamente i messaggi alla scadenza del lease. Il metodo più comune è utilizzare il RENEWLEASE_QUEUE_NAME() TVF.

Inoltre, tieni presente questi comportamenti principali delle code Spanner:

  • Distribuzione "at-least-once":comune alla maggior parte dei sistemi di code basati sul cloud, Spanner promette la distribuzione "at-least-once". Le riconsegne possono essere mitigate estendendo i contratti di locazione.
  • Riconoscimento al massimo una volta: poiché il riconoscimento di un messaggio avviene tramite una transazione, la semantica ACID di Spanner garantisce che un messaggio venga riconosciuto una sola volta. Segui i metodi indicati nella pagina Elaborazione "exactly-once" e riconoscimento "at-most-once" per implementare correttamente il riconoscimento "at-most-once".

Limitazioni

Le code Spanner presentano le seguenti limitazioni:

  • Numero massimo di destinatari:esiste un limite di 1000 query di ricezione attive con gli stessi argomenti per coda
  • Limite di quota TVF di ricezione simultanea:esiste un limite di quota di 2000 TVF di ricezione simultanea per progetto per regione. Per aumentare il limite di quota, compila il modulo Richiedi un aumento della quota per il tuo progetto Cloud Spanner.
  • Suddivisione manuale:l'API AddSplits non è supportata per le code. La distribuzione del carico di lavoro si basa interamente sulla suddivisione basata sul carico. È consigliabile alternare la coda in una tabella in modo che gli utenti possano aggiungere punti di divisione alla tabella.
  • Conformità al partizionamento geografico:le code con partizionamento geografico non sono conformi alla residenza dei dati dopo l'esecuzione di un'operazione DROP PARTITION.
  • Limiti del conteggio delle code:le istanze sono limitate a 100 code per le istanze con uno o più nodi. Il limite viene ridotto proporzionalmente per le istanze granulari (ad esempio, le istanze con 200 unità di elaborazione sono limitate a 20 code).
  • Eliminazione e ricreazione di una coda: l'eliminazione e la ricreazione di una coda con lo stesso nome non sono completamente supportate. Potrebbe essere necessario del tempo prima che il RECEIVE TVF per la coda venga "reimpostato" prima che i messaggi possano essere ricevuti di nuovo con lo stesso nome.
  • Denominazione delle colonne PostgreSQL:Spanner espone le colonne deliver_time e DeliverTime per i tempi di consegna di un messaggio. Ti consigliamo di utilizzare la colonna deliver_time per allinearti alle convenzioni di denominazione standard di PostgreSQL e perché la colonna DeliverTime verrà nascosta dallo schema informativo in una release futura.
  • Schema denominato:le code non possono essere create negli schemi denominati.

Passaggi successivi