Escolha um tipo de assinatura

Este documento apresenta uma visão geral de como diferentes tipos de assinatura funcionam no Pub/Sub.

Visão geral da assinatura

Para receber as mensagens publicadas em um tópico, crie uma assinatura para ele. Somente as mensagens publicadas sobre o tópico após a criação da assinatura ficam disponíveis para os clientes assinantes. No entanto, você também pode ativar a retenção de tópicos para permitir que uma assinatura associada ao tópico volte no tempo e repita as mensagens publicadas anteriormente. O cliente do assinante recebe e processa as mensagens publicadas no tópico. Um tópico pode ter várias assinaturas, mas cada assinatura pertence somente a um tópico.

Fluxo de trabalho de assinatura

  1. Após ser enviada a um assinante, o assinante precisa confirmar a mensagem.

  2. Se uma mensagem for enviada para entrega e um assinante ainda não a tiver confirmado, a mensagem será chamada como pendente.

  3. O Pub/Sub tenta entregar repetidamente qualquer mensagem que ainda não tenha sido confirmada. No entanto, o Pub/Sub tenta não entregar uma mensagem pendente a nenhum outro assinante na mesma assinatura.

  4. O assinante tem um período configurável e limitado, conhecido como ackDeadline, para confirmar a mensagem pendente. Após o prazo, a mensagem não será mais considerada pendente, e o Pub/Sub tentará reenviá-la.

Tipos de assinatura

Ao criar uma assinatura, você precisa especificar o tipo de entrega de mensagens. O Pub/Sub oferece três tipos de entrega de mensagens que correspondem aos três seguintes tipos de assinaturas. Cada tipo de assinatura é descrito resumidamente nas próximas seções deste documento.

  • Assinatura de pull
  • Assinatura de push
  • Assinatura do BigQuery

Você pode atualizar o tipo de assinatura a qualquer momento.

Assinatura de pull

Para uma assinatura pull, o cliente assinante inicia solicitações a um servidor do Pub/Sub para recuperar mensagens. O cliente do assinante usa a API REST Pull, a API PullRequest RPC, a API REST StreamingPullRequest ou a API RPC RPC. A maioria dos clientes de inscritos não faz essas solicitações diretamente. Em vez disso, os clientes dependem da biblioteca de alto nível do Google Cloud fornecida pelo Google Cloud que executa solicitações de envio de streaming internamente e entrega mensagens de maneira assíncrona. Para um cliente inscrito que precisa de maior controle sobre como as mensagens são extraídas, o Pub/Sub usa uma biblioteca gRPC de baixo nível e gerada automaticamente. Essa biblioteca faz solicitações de envio diretamente ou por streaming. Essas solicitações podem ser síncronas ou assíncronas.

As duas imagens a seguir mostram o fluxo de trabalho entre um cliente assinante e uma assinatura pull.

Fluxo de mensagens para uma assinatura de pull
Figura 1. Fluxo de trabalho para uma assinatura de pull


Fluxo de mensagens para uma
assinatura streamingPull
Figura 2. Fluxo de trabalho para uma assinatura de pull de streaming

O fluxo de trabalho de pull é o seguinte e se refere à Figura 1:

  1. O cliente assinante chama explicitamente o método pull, que solicita mensagens para entrega. Essa solicitação é o PullRequest, conforme mostrado na imagem.

  2. O servidor Pub/Sub responde com zero ou mais mensagens e IDs de confirmação. Uma resposta com zero mensagens ou com um erro não indica necessariamente que não há mensagens disponíveis para receber. Essa resposta é a PullResponse conforme mostrado na imagem.

  3. O cliente inscrito chama explicitamente o método confirmado. O cliente usa o ID de confirmação retornado para confirmar que a mensagem foi processada e não precisa ser entregue novamente. Essa solicitação é a AckRequest, conforme mostrado na imagem.

Para uma única solicitação de envio de streaming, um cliente assinante pode ter várias respostas retornadas devido à conexão aberta. Por outro lado, apenas uma resposta é retornada para cada solicitação de envio.

Para saber mais sobre como uma assinatura pull funciona e exemplos de configuração, consulte Assinaturas pull.

Assinatura de push

Em uma assinatura push, um servidor Pub/Sub inicia uma solicitação ao seu cliente assinante para entregar mensagens.

A imagem a seguir mostra o fluxo de trabalho entre um cliente assinante e uma assinatura push.

Fluxo de mensagens para uma assinatura push
Figura 3. Fluxo de trabalho para uma assinatura push

Veja uma breve descrição do fluxo de trabalho que se refere à Figura 3:

  1. O servidor do Pub/Sub envia cada mensagem como uma solicitação HTTPS para o cliente assinante em um endpoint pré-configurado. Essa solicitação é exibida como uma PushRequest na imagem.

  2. O endpoint confirma a mensagem retornando um código de status de sucesso HTTP. Uma resposta sem sucesso indica que o Pub/Sub precisa reenviar as mensagens. Essa resposta é exibida como uma PushResponse na imagem.

  3. O Pub/Sub ajusta dinamicamente a taxa de solicitações de push com base na taxa em que recebe respostas bem-sucedidas.

Para saber mais sobre como uma assinatura de push funciona e exemplos de configuração, consulte Assinaturas de push.

Assinatura do BigQuery

Uma assinatura do BigQuery grava mensagens em uma tabela existente do BigQuery conforme elas são recebidas. Você não precisa configurar um cliente de assinante separado.

Sem o tipo de assinatura do BigQuery, você precisa de uma assinatura pull ou push e de um assinante (como o Dataflow) que leia as mensagens e as grave em uma tabela do BigQuery. A sobrecarga de executar um job do Dataflow não é necessária quando as mensagens não exigem processamento adicional antes de serem armazenadas em uma tabela do BigQuery. Use uma assinatura do BigQuery. No entanto, ainda é recomendado um pipeline do Dataflow para sistemas Pub/Sub em que seja necessária alguma transformação de dados para que eles sejam armazenados em uma tabela do BigQuery. Para saber como transmitir dados do Pub/Sub para o BigQuery com transformação usando o Dataflow, consulte Transmitir do Pub/Sub para o BigQuery.

A imagem a seguir mostra o fluxo de trabalho entre uma assinatura do BigQuery e o BigQuery.

Fluxo de mensagens para uma assinatura do BigQuery
Figura 4. Fluxo de trabalho para uma assinatura do BigQuery

Veja uma breve descrição do fluxo de trabalho que faz referência à Figura 4:

  1. O Pub/Sub usa a API BigQuery Storage Write para enviar dados à tabela do BigQuery.
  2. As mensagens são enviadas em lotes para a tabela do BigQuery.
  3. Após a conclusão de uma operação de gravação, a API retorna uma resposta OK.
  4. Se houver falhas na operação de gravação, a mensagem do Pub/Sub será confirmada. A mensagem será reenviada. Se a mensagem falhar o suficiente e houver um tópico de mensagens inativas configurado na assinatura, a mensagem será movida para o tópico de mensagens inativas.

Para saber mais sobre o funcionamento de uma assinatura do BigQuery, consulte Assinaturas do BigQuery.

Decida o tipo de assinatura

A tabela a seguir oferece uma orientação para escolher o mecanismo de entrega adequado para seu aplicativo:

  Pull Push BigQuery
Caso de uso
  • Grande volume de mensagens (GBs por segundo).
  • A eficiência e a capacidade do processamento da mensagem são fundamentais.
  • Ambientes em que não é viável configurar um endpoint HTTPS público com um certificado SSL não autoassinado.
  • Vários tópicos que precisam ser processados pelo mesmo webhook.
  • Assinantes do Cloud Functions e do ambiente padrão do Google App Engine.
  • Ambientes em que não é viável configurar dependências do Google Cloud (como credenciais e biblioteca de cliente).
  • Grande volume de mensagens que podem ser escalonadas para vários milhões de mensagens por segundo
  • As mensagens são enviadas diretamente para o BigQuery, sem processamento adicional.
Endpoints Qualquer dispositivo na Internet com credenciais autorizadas pode chamar a API Pub/Sub. Um servidor HTTPS com certificado não autoassinado acessível na Web pública. O endpoint de recebimento pode estar desacoplado da assinatura do Pub/Sub. Assim, as mensagens de várias assinaturas podem ser enviadas para um único endpoint. Uma tabela do BigQuery.
Balanceamento de carga Vários assinantes podem fazer chamadas pull para a mesma assinatura "shared" Cada assinante recebe um subconjunto das mensagens. O ponto de extremidade de push pode ser um balanceador de carga. O serviço Pub/Sub equilibra automaticamente a carga.
Configuration Não é necessário configurar. Nenhuma configuração é necessária para aplicativos do App Engine no mesmo projeto do assinante.
A verificação de endpoints de push não é necessária no Console do Google Cloud. Os endpoints precisam ser acessíveis usando nomes DNS e ter certificados SSL instalados.
É necessário que exista uma tabela do BigQuery para a assinatura do tópico.
Controle de fluxo O cliente do assinante controla a taxa de entrega. O assinante pode modificar dinamicamente o prazo de confirmação, permitindo que o processamento de mensagens seja arbitrariamente longo. O servidor do Pub/Sub implementa automaticamente o controle de fluxo. Não é necessário processar o fluxo de mensagens no lado do cliente. No entanto, é possível indicar que o cliente não consegue processar a carga atual da mensagem retornando um erro de HTTP. O servidor do Pub/Sub implementa automaticamente o controle de fluxo para otimizar a gravação de mensagens no BigQuery.
Eficiência e capacidade Alcance uma alta capacidade de processamento com baixa CPU e largura de banda, permitindo a entrega em lote e confirmações, bem como o consumo paralelo massivo. Pode ser ineficiente se a pesquisa agressiva for usada para minimizar o tempo de entrega da mensagem. Entrega uma mensagem por solicitação e limita o número máximo de mensagens pendentes. A escalonabilidade é processada dinamicamente pelos servidores do Pub/Sub.

Propriedades de assinatura padrão

Por padrão, o Pub/Sub oferece entrega pelo menos uma vez sem garantias de ordenação em todos os tipos de assinatura. Como alternativa, se as mensagens tiverem a mesma chave de ordem e estiverem na mesma região, é possível ativar a ordenação de mensagens. Depois de definir a propriedade de ordenação de mensagens, o serviço Pub/Sub entrega mensagens com a mesma chave de ordem e na ordem em que o serviço Pub/Sub recebe as mensagens.

O Pub/Sub também é compatível com entrega exatamente uma vez no modo de visualização.

Em geral, o Pub/Sub entrega cada mensagem uma vez e na ordem em que foi publicada. No entanto, às vezes as mensagens podem ser entregues fora de ordem ou mais de uma vez. Acomodação de entrega mais de uma vez exige que o assinante seja idempotente ao processar mensagens.

Validade da assinatura

Por padrão, as assinaturas expiram após 31 dias de inatividade ou se não houver atualizações na assinatura. Exemplos de atividades dos assinantes incluem conexões abertas, pulls ativos ou pushes bem-sucedidos. Se o Pub/Sub detectar a atividade do assinante ou uma atualização das propriedades da assinatura, o relógio de exclusão de assinatura será reiniciado. Com as políticas de expiração de assinatura, é possível configurar a duração da inatividade ou tornar a assinatura permanente, independentemente da atividade. Também é possível excluir uma assinatura manualmente.

Embora você possa criar uma nova assinatura com o mesmo nome de uma excluída, a nova assinatura não tem relação com a antiga. Mesmo que a assinatura excluída tivesse muitas mensagens não confirmadas, uma nova assinatura criada com o mesmo nome não teria backlog (nenhuma mensagem aguardando entrega) no momento em que ela foi criada.

Para saber mais sobre como trabalhar com assinaturas, consulte Criar e usar assinaturas.

A seguir