Panoramica delle code Spanner

Le code di Spanner forniscono messaggi transazionali per aiutarti a gestire il lavoro asincrono. La funzionalità abbina questa capacità alla scalabilità e all'affidabilità di Spanner, consentendoti di creare applicazioni basate sugli eventi. Le code di Spanner utilizzano un modello pull per il consumo dei messaggi, esponendo un'interfaccia SQL per consentire ai destinatari di richiedere e ricevere messaggi.

Scegli tra code Spanner e modifiche in tempo reale

Il seguente confronto fornisce indicazioni su come scegliere il meccanismo giusto per la propagazione dei dati e l'elaborazione asincrona.

Code Spanner

Ideale per

  • Notifiche degli eventi transazionali
  • Esecuzione di lavori pianificati per il futuro
  • Logica di conferma per messaggio

Caratteristiche principali

  • Payload dei messaggi di piccole dimensioni definiti dall'utente
  • Modello pull per l'utilizzo dei messaggi
  • Scalabilità con il computing delle istanze Spanner

Modifiche in tempo reale di Spanner

Ideale per

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

Caratteristiche principali

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

Principali vantaggi

Le code di 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 delle applicazioni e riduce i costi complessivi.
  • Transazionale: puoi inviare e confermare i messaggi in modo atomico all'interno di una transazione Spanner insieme ad altre scritture nel database. Se la transazione non va a buon fine, viene eseguito il rollback dei messaggi in coda, che non sono disponibili per la consegna.
  • Durevole: i messaggi che non possono essere recapitati vengono archiviati nel database. Spanner tenta continuamente di recapitare il messaggio con backoff finché non viene confermato o eliminato esplicitamente.
  • Queryable: i messaggi sono basati sulle stesse primitive delle tabelle Spanner e vengono archiviati come righe. Puoi eseguire query, join o filtri come faresti con le tabelle standard.
  • Scalabile: l'elaborazione dei messaggi, basata sulla stessa scalabilità delle tabelle Spanner, si adatta al resto del database.
  • Affidabilità: le code di 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 a livello di zona o regione.
  • Pianificabile: i messaggi possono essere pianificati per l'invio futuro, consentendoti di posticipare l'esecuzione delle attività a un timestamp futuro specifico.
  • Atomico: l'invio dei messaggi (API INSERT o di mutazione) e l'acknowledgement (API DELETE o di mutazione) vengono eseguiti in modo atomico all'interno delle transazioni, garantendo la coerenza con lo stato del database.
  • Estendibili: i lease dei messaggi possono essere estesi per supportare tempi di elaborazione estremamente lunghi combinando i meccanismi di consegna futura e di leasing manuale.

Casi d'uso

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

  • Rinvio di attività ad alta intensità 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 in coda. In un secondo momento, un ricevitore della coda preleva il messaggio, esegue l'elaborazione e aggiorna i metadati in modo transazionale.
  • Rinvio di aggiornamenti transazionali di grandi dimensioni: in un'app di calendario, invitare un gruppo numeroso 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 di coda per ogni invitato, consentendo a un ricevitore 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 accodare un messaggio pianificato per essere recapitato tra 30 giorni. Un worker riceve quindi il messaggio ed esegue la logica di scadenza della prova.
  • Rinvio del lavoro a sistemi esterni: dopo la registrazione di un utente, un'applicazione potrebbe dover inviare un'email di benvenuto solo se la registrazione al database va a buon fine. La transazione di registrazione può aggiungere una voce a una coda, consentendo a un worker di richiamare un'API email esterna in un secondo momento.
  • Orchestrazione di pipeline in più passaggi: 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 in coda, il sistema può creare un checkpoint dello stato della pipeline e continuare dal punto di errore.

Workflow

Un workflow tipico per le code di Spanner segue questi passaggi:

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

Inoltre, tieni presente questi comportamenti principali delle code di Spanner:

  • Consegna at-least-once: come la maggior parte dei sistemi di coda basati su cloud, Spanner promette la consegna at-least-once. I nuovi invii possono essere mitigati estendendo i lease.
  • Conferma at-most-once: poiché la conferma di un messaggio avviene tramite una transazione, la semantica ACID di Spanner garantisce che un messaggio venga confermato una sola volta. Segui i metodi descritti nella pagina Elaborazione "exactly-once" e conferma "at-most-once" per implementare correttamente la conferma "at-most-once".

Limitazioni

Le code di 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 per le TVF di ricezione simultanea:esiste un limite di quota di 2000 TVF di ricezione simultanea per progetto per regione. Per aumentare il limite della 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 workload si basa interamente sulla suddivisione basata sul carico. È consigliabile intercalare la coda in una tabella in modo che gli utenti possano aggiungere punti di suddivisione 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 numero di code: le istanze sono limitate a 100 code per le istanze con 1 o più nodi. Il limite viene ridotto in modo proporzionale per le istanze granulari (ad esempio, le istanze con 200 unità di elaborazione sono limitate a 20 code).
  • Nomi delle colonne PostgreSQL: Spanner espone sia le colonne deliver_time che DeliverTime per i tempi di consegna di un messaggio. Ti consigliamo di utilizzare la colonna deliver_time per rispettare le convenzioni di denominazione standard di PostgreSQL e perché la colonna DeliverTime verrà nascosta dallo schema delle informazioni in una release futura.
  • Schema denominato: non è possibile creare code negli schemi denominati.

Passaggi successivi