Visão geral das filas do Spanner

As filas do Spanner oferecem mensagens transacionais para gerenciar o trabalho assíncrono. O recurso combina essa capacidade com a escalonabilidade e a confiabilidade do Spanner, permitindo que você crie aplicativos orientados a eventos. As filas do Spanner usam um modelo de pull para consumo de mensagens, expondo uma interface SQL para que os destinatários solicitem e recebam mensagens.

Escolher entre filas do Spanner e fluxo de alterações

A comparação a seguir fornece orientações sobre como escolher o mecanismo certo para propagação de dados e processamento assíncrono.

Filas do Spanner

Ideal para

  • Notificações de eventos transacionais
  • Execução de trabalho programada para o futuro
  • Lógica de confirmação por mensagem

Principais características

  • Payloads de mensagens pequenos e definidos pelo usuário
  • Modelo de pull para consumo de mensagens
  • Escalonamento com a computação da instância do Spanner

Fluxos de alterações do Spanner

Ideal para

  • Replicação de dados de alta capacidade de processamento
  • Sincronização de caches ou índices downstream
  • Registro de auditoria de todas as alterações no banco de dados

Principais características

  • Captura todos os fragmentos de registro (até 10 MB)
  • Streaming baseado em pull usando tokens de partição
  • Inclui heartbeats e checkpoints

Veja as principais vantagens

As filas do Spanner oferecem várias vantagens:

  • Integrado:as mensagens são integradas ao banco de dados. Isso elimina a necessidade de provisionar, gerenciar e exfiltrar dados para uma infraestrutura de mensagens separada, o que simplifica a arquitetura do aplicativo e reduz os custos gerais.
  • Transacional:é possível enviar e confirmar mensagens de maneira atômica em uma transação do Spanner com outras gravações de banco de dados. As mensagens enfileiradas são revertidas e não ficam disponíveis para entrega se a transação falhar.
  • Durável:as mensagens que não podem ser entregues são armazenadas no banco de dados. O Spanner tenta continuamente entregar com espera até que a mensagem seja explicitamente confirmada ou excluída.
  • Consultáveis:as mensagens são criadas nas mesmas primitivas que as tabelas do Spanner e são armazenadas como linhas. É possível consultar, mesclar ou filtrar essas tabelas como as padrão.
  • Escalonável:criado com a mesma escalonabilidade das tabelas do Spanner, o processamento de mensagens é escalonado junto com o restante do banco de dados.
  • Confiável:as filas do Spanner herdam todas as primitivas de alta disponibilidade do Spanner, tornando o envio e o processamento de mensagens tolerantes a falhas e resilientes a falhas zonais ou regionais.
  • Programável:as mensagens podem ser programadas para entrega futura, permitindo que você atrase a execução da tarefa para um carimbo de data/hora futuro específico.
  • Atômico:o envio de mensagens (APIs INSERT ou de mutação) e a confirmação (APIs DELETE ou de mutação) são executados de forma atômica nas transações, garantindo a consistência com o estado do banco de dados.
  • Extensível:as locações de mensagens podem ser estendidas para oferecer suporte a tempos de processamento extremamente longos, combinando mecanismos de entrega futura e locação manual.

Casos de uso

As filas do Spanner são úteis para orquestrar tarefas adiadas em uma transação. São exemplos comuns:

  • Adiar o trabalho computacionalmente pesado:um site de compartilhamento de fotos pode precisar realizar um processamento intensivo de imagens quando uma nova foto é enviada. A transação que grava os novos metadados da foto pode gravar simultaneamente uma mensagem de fila. Um receptor de fila coleta a mensagem, realiza o processamento e atualiza os metadados de forma transacional.
  • Adiar grandes atualizações transacionais:em um app de agenda, convidar um grupo grande para uma reunião em uma única transação pode causar conflitos de bloqueio e latências de cauda. Em vez disso, a transação que cria o item da agenda pode adicionar uma entrada de fila para cada convidado, permitindo que um receptor envie os convites individualmente.
  • Programação de tarefas no futuro:uma empresa de software como serviço (SaaS) que oferece um teste sem custo financeiro de 30 dias pode provisionar os recursos do usuário e, ao mesmo tempo, colocar em fila uma mensagem programada para ser entregue em 30 dias. Em seguida, um worker recebe a mensagem e executa a lógica de expiração do teste.
  • Adiar o trabalho para sistemas externos:depois que um usuário se registra, um aplicativo pode precisar enviar um e-mail de boas-vindas somente se o registro do banco de dados for bem-sucedido. A transação de registro pode adicionar uma entrada a uma fila, permitindo que um worker invoque uma API de e-mail externa mais tarde.
  • Orquestração de pipelines de várias etapas:em um sistema de gerenciamento de pedidos, atender a um pedido envolve várias etapas que podem falhar de forma independente. Ao representar cada etapa como uma mensagem de fila, o sistema pode criar um checkpoint do estado do pipeline e continuar do ponto de falha.

Fluxo de trabalho

Um fluxo de trabalho típico para filas do Spanner segue estas etapas:

  • Criar uma fila:defina uma fila usando DDL, de forma semelhante a uma tabela. Ela precisa incluir uma coluna Payload (payload no PostgreSQL) e uma chave primária.
  • Enviar mensagens:coloque mensagens em fila usando DML padrão (INSERT) ou APIs de mutação, de forma transacional com outras operações de banco de dados.
  • Receber mensagens:use a API ExecuteStreamingSQL para chamar uma função com valor de tabela (TVF, na sigla em inglês) chamada RECEIVE_QUEUE_NAME(). Essa função transmite mensagens para o cliente como uma consulta de longa duração.
  • Processar mensagens:consuma as mensagens recebidas da TVF com a lógica do aplicativo.
  • Confirmar mensagens:remova mensagens da fila usando DML (DELETE) ou APIs de mutação (como ack). Isso geralmente é feito após a conclusão do processamento, em uma transação.
  • Gerenciar locações:gerencie as locações de mensagens para garantir que as filas do Spanner não reenviem mensagens no tempo limite da locação. O método mais comum é usar a TVF RENEWLEASE_QUEUE_NAME().

Além disso, lembre-se destes comportamentos principais das filas do Spanner:

  • Entrega pelo menos uma vez:comum à maioria dos sistemas de fila baseados na nuvem, o Spanner promete a entrega pelo menos uma vez. As novas entregas podem ser mitigadas com a extensão de leases.
  • Confirmação no máximo uma vez:como a confirmação de uma mensagem acontece em uma transação, a semântica ACID do Spanner garante que uma mensagem seja confirmada apenas uma vez. Seguir os métodos na página Processamento único e confirmação no máximo uma vez para implementar corretamente a confirmação no máximo uma vez.

Limitações

As filas do Spanner têm as seguintes limitações:

  • Máximo de receptores:há um limite de 1.000 consultas de recebimento ativas com os mesmos argumentos por fila.
  • Limite de cota de TVF de recebimento simultâneo:há um limite de cota de 2.000 TVFs de recebimento simultâneo por projeto e por região. Para aumentar o limite de cota, preencha o formulário Solicitar um aumento de cota para seu projeto do Cloud Spanner.
  • Divisão manual:a API AddSplits não é compatível com filas. A distribuição de cargas de trabalho depende inteiramente da divisão com base na carga. É recomendável intercalar a fila em uma tabela para que os usuários possam adicionar pontos de divisão à tabela.
  • Conformidade com o particionamento geográfico:as filas com particionamento geográfico não estão em conformidade com a residência de dados após a execução de uma operação DROP PARTITION.
  • Limites de contagem de filas:as instâncias são limitadas a 100 filas para instâncias com um ou mais nós. O limite reduz escala vertical proporcionalmente para instâncias granulares (por exemplo, instâncias com 200 unidades de processamento são limitadas a 20 filas).
  • Nomeação de colunas do PostgreSQL:o Spanner expõe as colunas deliver_time e DeliverTime para o horário de entrega de uma mensagem. Recomendamos usar a coluna deliver_time para se alinhar às convenções de nomenclatura padrão do PostgreSQL e porque a coluna DeliverTime será ocultada do esquema de informações em uma versão futura.
  • Esquema nomeado:não é possível criar filas em esquemas nomeados.

A seguir