Subscrições de obtenção

Este documento fornece uma vista geral de uma subscrição de obtenção, do respetivo fluxo de trabalho e das propriedades associadas.

Numa subscrição de obtenção, um cliente subscritor pede mensagens ao servidor do Pub/Sub.

O modo de obtenção pode usar uma das duas APIs de serviço, Pull ou StreamingPull. Para executar a API escolhida, pode selecionar uma biblioteca de cliente de alto nível fornecida pela Google ou uma biblioteca de cliente de baixo nível gerada automaticamente. Também pode escolher entre o processamento de mensagens assíncrono e síncrono.

Antes de começar

Antes de ler este documento, certifique-se de que conhece o seguinte:

Fluxo de trabalho de subscrição de obtenção

Para uma subscrição de obtenção, o cliente subscritor inicia pedidos a um servidor do Pub/Sub para obter mensagens. O cliente subscritor usa uma das seguintes APIs:

A maioria dos clientes subscritores não faz estes pedidos diretamente. Em vez disso, os clientes confiam na biblioteca cliente de alto nível fornecida pela Google que executa pedidos de obtenção de streaming internamente e envia mensagens de forma assíncrona. Trusted Cloud by S3NSPara um cliente subscritor que necessita de maior controlo sobre a forma como as mensagens são extraídas, o Pub/Sub usa uma biblioteca gRPC de baixo nível e gerada automaticamente. Esta biblioteca faz pedidos de obtenção ou de obtenção de streaming diretamente. Estes pedidos podem ser síncronos ou assíncronos.

As duas imagens seguintes mostram o fluxo de trabalho entre um cliente subscritor e uma subscrição de obtenção.

Fluxo de mensagens para uma subscrição de obtenção
Figura 1. Fluxo de trabalho para uma subscrição de obtenção



Fluxo de mensagens para uma subscrição streamingPull
Figura 2. Fluxo de trabalho para uma subscrição de obtenção de streaming

Fluxo de trabalho de obtenção

O fluxo de trabalho de obtenção é o seguinte e refere-se à Figura 1:

  1. O cliente subscritor chama explicitamente o método pull, que pede mensagens para entrega. Esta 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 existem mensagens disponíveis para receção. Esta resposta é o PullResponse, conforme mostrado na imagem.

  3. O cliente subscritor chama explicitamente o método acknowledge. O cliente usa o ID de confirmação devolvido para confirmar que a mensagem foi processada e não tem de ser entregue novamente.

Para um único pedido de obtenção de streaming, um cliente subscritor pode ter várias respostas devolvidas devido à ligação aberta. Por outro lado, é devolvida apenas uma resposta para cada pedido de obtenção.

Propriedades de uma subscrição de obtenção

As propriedades que configurar para uma subscrição de obtenção determinam como escreve mensagens na sua subscrição. Para mais informações, consulte o artigo Propriedades da subscrição.

APIs de serviço Pub/Sub

A subscrição de obtenção do Pub/Sub pode usar uma das seguintes duas APIs para obter mensagens:

  • Obtenção
  • StreamingPull

Use RPCs unários Acknowledge e ModifyAckDeadline quando receber mensagens através destas APIs. As duas APIs Pub/Sub estão descritas nas secções seguintes.

API StreamingPull

Sempre que possível, as bibliotecas de cliente do Pub/Sub usam o StreamingPull para um débito máximo e uma latência mínima. Embora possa nunca usar a API StreamingPull diretamente, é importante saber como difere da API Pull.

A API StreamingPull baseia-se numa ligação bidirecional persistente para receber várias mensagens à medida que ficam disponíveis. Segue-se o fluxo de trabalho:

  1. O cliente envia um pedido ao servidor para estabelecer uma ligação. Se a quota de ligações for excedida, o servidor devolve um erro de recurso esgotado. A biblioteca de cliente tenta novamente os erros de falta de quota automaticamente.

  2. Se não existir nenhum erro ou a quota de ligações estiver novamente disponível, o servidor envia continuamente mensagens ao cliente ligado.

  3. Se ou quando a quota de débito for excedida, o servidor deixa de enviar mensagens. No entanto, a ligação não é interrompida. Sempre que houver novamente quota de débito suficiente, a transmissão é retomada.

  4. O cliente ou o servidor acabam por fechar a ligação.

A API StreamingPull mantém uma ligação aberta. Os servidores do Pub/Sub fecham recorrentemente a ligação após um período para evitar uma ligação persistente de longa duração. A biblioteca de cliente reabre automaticamente uma ligação StreamingPull.

As mensagens são enviadas para a ligação quando estão disponíveis. Assim, a API StreamingPull minimiza a latência e maximiza o débito para as mensagens.

Leia mais acerca dos métodos RPC StreamingPull: StreamingPullRequest e StreamingPullResponse.

API Pull

Esta API é um RPC unário tradicional baseado num modelo de pedido e resposta. Uma única resposta de obtenção corresponde a um único pedido de obtenção. Segue-se o fluxo de trabalho:

  1. O cliente envia um pedido de mensagens ao servidor. Se a quota de débito for excedida, o servidor devolve um erro de recurso esgotado.

  2. Se não existir nenhum erro ou a quota de débito estiver novamente disponível, o servidor responde com zero ou mais mensagens e IDs de confirmação.

Quando usa a API Pull unária, uma resposta com zero mensagens ou com um erro não indica necessariamente que não existem mensagens disponíveis para receber.

A utilização da API Pull não garante uma baixa latência nem um elevado débito de mensagens. Para alcançar um elevado débito e uma baixa latência com a API Pull, tem de ter vários pedidos pendentes em simultâneo. São criados novos pedidos quando os pedidos antigos recebem uma resposta. A arquitetura de uma solução deste tipo é propensa a erros e difícil de manter. Recomendamos que use a API StreamingPull para esses exemplos de utilização.

Use a API Pull em vez da API StreamingPull apenas se precisar de um controlo rigoroso sobre o seguinte:

  • O número de mensagens que o cliente subscritor pode processar
  • A memória e os recursos do cliente

Também pode usar esta API quando o subscritor é um proxy entre o Pub/Sub e outro serviço que funciona de uma forma mais orientada para a obtenção.

Leia mais acerca dos métodos REST de obtenção: Método: projects.subscriptions.pull.

Leia mais acerca dos métodos RPC Pull: PullRequest e PullResponse.

Tipos de modos de processamento de mensagens

Escolha um dos seguintes modos de obtenção para os clientes subscritores.

Modo de obtenção assíncrono

O modo de obtenção assíncrono desvincula a receção de mensagens do processamento de mensagens num cliente subscritor. Este modo é o predefinido para a maioria dos clientes subscritores. O modo de obtenção assíncrono pode usar a API StreamingPull ou a API Pull unária. A obtenção assíncrona também pode usar a biblioteca de cliente de alto nível ou a biblioteca de cliente de baixo nível gerada automaticamente.

Pode saber mais acerca das bibliotecas de cliente mais adiante neste documento.

Modo de obtenção síncrono

No modo de obtenção síncrono, a receção e o processamento de mensagens ocorrem em sequência e não estão separados. Assim, de forma semelhante às APIs StreamingPull versus unary Pull, o processamento assíncrono oferece uma latência inferior e um débito mais elevado do que o processamento síncrono.

Use o modo de obtenção síncrono apenas para aplicações em que a latência baixa e o débito elevado não são os fatores mais importantes em comparação com outros requisitos. Por exemplo, uma aplicação pode estar limitada à utilização apenas do modelo de programação síncrono. Em alternativa, uma aplicação com restrições de recursos pode exigir um controlo mais exato sobre a memória, a rede ou a CPU. Nestes casos, use o modo síncrono com a API Pull unária.

Bibliotecas cliente do Pub/Sub

O Pub/Sub oferece uma biblioteca de cliente gerada automaticamente de nível elevado e de nível baixo.

Biblioteca cliente Pub/Sub de alto nível

A biblioteca de cliente de alto nível oferece opções para controlar os prazos de confirmação através da gestão de concessões. Estas opções são mais detalhadas do que quando configura os prazos de confirmação através da consola ou da CLI ao nível da subscrição. A biblioteca do cliente de nível elevado também implementa suporte para funcionalidades como entrega ordenada, entrega exatamente uma vez e controlo de fluxo.

Recomendamos a utilização da obtenção assíncrona e da API StreamingPull com a biblioteca de cliente de alto nível. Nem todos os idiomas suportados paraTrusted Cloud by S3NS também suportam a API Pull na biblioteca cliente de nível elevado.

Para usar as bibliotecas cliente de nível elevado, consulte as bibliotecas cliente do Pub/Sub.

Biblioteca de cliente do Pub/Sub de baixo nível gerada automaticamente

Está disponível uma biblioteca cliente de baixo nível para os casos em que tem de usar a API Pull diretamente. Pode usar o processamento síncrono ou assíncrono com a biblioteca de cliente de baixo nível gerada automaticamente. Tem de codificar manualmente funcionalidades como a entrega ordenada, a entrega exatamente uma vez, o controlo de fluxo e a gestão de concessões quando usa a biblioteca de cliente de baixo nível gerada automaticamente.

Pode usar o modelo de processamento síncrono quando usa a biblioteca cliente gerada automaticamente de baixo nível para todos os idiomas suportados. Pode usar a biblioteca cliente de baixo nível gerada automaticamente e a obtenção síncrona nos casos em que faz sentido usar diretamente a API Pull. Por exemplo, pode ter uma lógica de aplicação existente que dependa deste modelo.

Para usar diretamente as bibliotecas cliente geradas automaticamente de baixo nível, consulte a vista geral das APIs Pub/Sub.

O que se segue?