Escolha um tipo de assinatura

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

Visão geral da assinatura

Para receber mensagens publicadas em um tópico, crie uma assinatura dele. Somente mensagens publicadas no tópico após a criação da assinatura estão disponíveis para clientes assinantes. No entanto, você também pode ativar a retenção de tópicos para permitir que uma assinatura anexada ao tópico retorne e veja novamente as mensagens publicadas anteriormente. O cliente assinante recebe e processa as mensagens publicadas no tópico. Um tópico pode ter várias assinaturas, mas uma assinatura pertence a um único tópico.

Fluxo de trabalho de assinatura

  1. Depois que uma mensagem é enviada, o assinante precisa confirmar a mensagem.

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

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

  4. O assinante tem um período configurável, limitado e conhecido como ackDeadline, para confirmar a mensagem pendente. Depois que o prazo passar, 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 da mensagem. O Pub/Sub oferece dois tipos de entrega de mensagens que correspondem aos dois tipos de assinatura a seguir. Cada tipo de assinatura é descrito brevemente nas próximas seções deste documento.

  • Assinatura de pull
  • Assinatura de push

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

Assinatura de pull

Para uma assinatura de pull, seu cliente do assinante inicia solicitações para um servidor do Pub/Sub para recuperar mensagens usando a API REST Pull , a API PullRequest PullRequest, a API REST StreamingPullRequest ou a API RPC StreamingPullRequest. A maioria dos clientes assinantes não faz essas solicitações diretamente e dependem da biblioteca de cliente de alto nível fornecida pelo Google Cloud que executa solicitações de envio de streaming internamente e entrega mensagens de maneira assíncrona. Para um cliente assinante que precisa de mais controle sobre como as mensagens são extraídas, o Pub/Sub usa uma biblioteca gRPC de baixo nível e gerada automaticamente para fazer solicitações de pull ou streaming diretamente. 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 de pull.

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


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

O fluxo de trabalho de envio é o seguinte e faz referência à Figura 1:

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

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

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

A principal diferença entre os fluxos de trabalho pull e streaming é que, em uma única solicitação de envio por streaming, um cliente assinante pode ter várias respostas retornadas porque há uma conexão aberta. Por outro lado, apenas uma resposta é retornada para cada solicitação de envio.

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

Assinatura de push

Em uma assinatura de push, um servidor do Pub/Sub inicia uma solicitação para o cliente assinante enviar mensagens.

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

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

Veja uma breve descrição do fluxo de trabalho que faz referência à 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 a mensagem precisa ser reenviada. 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 de sucesso.

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

Defina o tipo de assinatura

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

  Pull Push
Caso de uso
  • Grande volume de mensagens (muitas mais de uma 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 a biblioteca de cliente.
Endpoints Qualquer dispositivo na Internet que tenha 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 ser dissociado da assinatura do Pub/Sub. Assim, as mensagens de várias assinaturas podem ser enviadas para um único endpoint.
Balanceamento de carga Vários inscritos podem fazer chamadas de 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.
Configuração 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.
Controle de fluxo O cliente do assinante controla a taxa de exibição. 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, embora seja possível indicar que o cliente não consegue processar a carga de mensagens atual com a transmissão de um erro de HTTP.
Eficiência e capacidade Atinge alta capacidade com pouca CPU e largura de banda, permitindo entregas e confirmações em lote, além de consumo massivo e paralelo. Pode ser ineficiente se uma 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.

Propriedades da assinatura padrão

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

O Pub/Sub também oferece suporte à entrega única no modo de visualização.

Em geral, o Pub/Sub entrega cada mensagem uma vez e na ordem em que foram publicadas. No entanto, às vezes as mensagens podem ser entregues fora de ordem ou mais de uma vez. Para acomodar a entrega mais de uma vez, o assinante precisa ser idempotente ao processar as mensagens.

Vencimento 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 de assinante incluem conexões abertas, pulls ativos ou pushs 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. Usando as políticas de expiração da assinatura, é possível configurar a duração da inatividade ou torná-la persistente independentemente da atividade. Também é possível excluir uma assinatura manualmente.

Embora seja possível 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 um grande número de mensagens não confirmadas, uma nova assinatura com nome idêntico não teria nenhum backlog (ou seja, nenhuma mensagem aguardando entrega) no momento da sua criação.

Para ver mais informações sobre como trabalhar com assinaturas, consulte Criar e usar assinaturas.

A seguir