Visão geral das filas do Spanner

As filas do Spanner oferecem mensagens transacionais para ajudar você a 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 extração para consumo de mensagens, expondo uma interface SQL para que os receptores solicitem e recebam mensagens.

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

A comparação a seguir oferece orientação 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 solicitação para consumo de mensagens
  • Escala com a computação de instâncias do Spanner

Fluxos de alterações do Spanner

Ideal para

  • Replicação de dados de alta capacidade
  • Sincronizar caches ou índices downstream
  • Geração de registros de auditoria de todas as mudanças no banco de dados

Principais características

  • Captura todos os fragmentos de gravação (até 10 MB)
  • Streaming baseado em pull usando tokens de partição
  • Inclui pulsações e checkpointing

Veja as principais vantagens

As filas do Spanner oferecem várias vantagens:

  • Integradas: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 junto com outras gravações no banco de dados. As mensagens enfileiradas são revertidas e não ficam disponíveis para entrega se a transação falhar.
  • Duráveis:as mensagens que não podem ser entregues são armazenadas no banco de dados. O Spanner tenta continuamente a entrega com espera exponencial 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, unir ou filtrar essas tabelas como tabelas 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áveis:as mensagens podem ser programadas para entrega futura, permitindo que você adie 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 o reconhecimento (APIs DELETE ou de mutação) são executados de maneira atômica em transações, garantindo a consistência com o estado do banco de dados.
  • Extensível:os contratos de mensagens podem ser estendidos para oferecer suporte a tempos de processamento extremamente longos combinando mecanismos de entrega futura e de contrato manual.

Casos de uso

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

  • Adiar trabalho computacionalmente pesado:um site de compartilhamento de fotos pode precisar realizar um processamento de imagens intensivo quando uma nova foto é enviada. A transação que grava os novos metadados da foto pode gravar simultaneamente uma mensagem na fila. Um receptor de fila pega a mensagem, realiza o processamento e atualiza os metadados de forma transacional.
  • Adiar grandes atualizações transacionais:em um app de agenda, convidar um grande grupo 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 destinatário envie os convites individualmente.
  • Agendamento de tarefas para o 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, enfileirar uma mensagem agendada 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 apenas 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, o atendimento de 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, semelhante a uma tabela. Ela precisa incluir uma coluna Payload (payload no PostgreSQL) e uma chave primária.
  • Enviar mensagens:enfileirar mensagens 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) chamada RECEIVE_QUEUE_NAME(). Essa função transmite mensagens para seu cliente como uma consulta de longa duração.
  • Processar mensagens:consuma as mensagens recebidas da TVF com a lógica do seu 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 concessões:gerencie as concessões de mensagens para garantir que as filas do Spanner não reenviem mensagens no tempo limite de concessã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 do tipo "pelo menos uma vez":comum à maioria dos sistemas de filas baseados na nuvem, o Spanner promete entrega do tipo "pelo menos uma vez". As reentregas podem ser evitadas com a extensão dos 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. Siga os métodos na página Processamento do tipo "exatamente uma vez" e confirmação do tipo "no máximo uma vez" para implementar corretamente a confirmação do tipo "no máximo uma vez".

Limitações

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

  • Número máximo de receptores:há um limite de 1.000 consultas de recebimento ativas com os mesmos argumentos por fila.
  • Limite de cota de TVFs de recebimento simultâneo:há um limite de cota de 2.000 TVFs de recebimento simultâneo por projeto e 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 carga de trabalho depende totalmente da divisão baseada em carga. É recomendável intercalar a fila em uma tabela para que os usuários possam adicionar pontos de divisão a ela.
  • Conformidade com o particionamento geográfico:as filas particionadas geograficamente 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 é reduzido proporcionalmente para instâncias granulares (por exemplo, instâncias com 200 unidades de processamento são limitadas a 20 filas).
  • Descartar e recriar uma fila:descartar e recriar uma fila com o mesmo nome não é totalmente compatível. A TVF RECEIVE da fila pode levar algum tempo para ser "redefinida" antes que as mensagens possam ser recebidas novamente com o mesmo nome.
  • Nomenclatura de colunas do PostgreSQL:o Spanner expõe as colunas deliver_time e DeliverTime para o tempo de entrega de uma mensagem. Recomendamos usar a coluna deliver_time para se alinhar às convenções de nomenclatura padrão do PostgreSQL, já que 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