Escolha um tipo de assinatura

Neste documento, apresentamos uma visão geral de como diferentes tipos de assinaturas funcionam no Pub/Sub.

Importante:saiba mais sobre uma assinatura, os diferentes tipos de assinatura e como escolher uma que seja adequada às suas necessidades de negócios.

Visão geral da assinatura

Para receber as mensagens publicadas em um tópico, crie uma assinatura para ele. Somente as mensagens publicadas no 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 anexada ao tópico volte no tempo e repita 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 cada assinatura pertence somente a um tópico.

Fluxo de trabalho de assinatura

1. Depois que uma mensagem for enviada a um assinante, ele precisará reconhecê-la.

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

3. O Pub/Sub tenta repetidamente entregar qualquer mensagem que ainda não foi 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. Depois que o prazo passa, a mensagem não é mais considerada pendente, e o Pub/Sub tenta 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 tipos de assinaturas a seguir. 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 de pull, o cliente do seu assinante inicia solicitações para 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 StreamingPullRequest. A maioria dos clientes 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 realiza solicitações de pull de streaming internamente e entrega as mensagens de maneira assíncrona. Para um cliente assinante 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 pull ou de 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 do assinante e uma assinatura de pull.

Figura 1. Fluxo de trabalho para uma assinatura de pull

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

O fluxo de trabalho de pull é mostrado abaixo e se refere à Figura 1:

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

2. O servidor do 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. 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 por streaming, um cliente do 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 mais informações sobre como uma assinatura de pull funciona e exemplos de configuração, consulte Assinaturas de 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.

Figura 3. Fluxo de trabalho para uma assinatura de 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 ao cliente do assinante em um endpoint pré-configurado. Essa solicitação aparece como 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 um 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 mais informações 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 atual do BigQuery à medida que elas são recebidas. Não é necessário configurar um cliente de assinante separado.

Sem o tipo de assinatura do BigQuery, você precisa de uma assinatura de pull ou push e de um assinante, como o Dataflow, que leia e grave mensagens 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 armazená-las em uma tabela do BigQuery. É possível usar uma assinatura do BigQuery. No entanto, ainda é recomendável um pipeline do Dataflow para sistemas Pub/Sub, em que uma transformação de dados é necessária para que os dados sejam armazenados em uma tabela do BigQuery. Para saber como fazer streaming de dados do Pub/Sub para o BigQuery com a transformação usando o Dataflow, consulte Fazer streaming do Pub/Sub para o BigQuery.

A imagem a seguir mostra o fluxo de trabalho entre uma assinatura do BigQuery e o 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 alguma falha na operação de gravação, a própria mensagem do Pub/Sub será reconhecida negativamente. A mensagem é 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 mais informações sobre como uma assinatura do BigQuery funciona, consulte Assinaturas do BigQuery.

Escolher seu tipo de assinatura

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

	Pull	Enviar	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 a biblioteca de cliente.	Grande volume de mensagens que podem ser escalonadas para até milhões de mensagens por segundo. As mensagens são enviadas diretamente para o BigQuery sem processamento adicional.
Endpoints	Qualquer dispositivo da Internet que tem 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 desacoplado da assinatura do Pub/Sub para que mensagens de várias assinaturas possam ser enviadas a um único endpoint.	Uma tabela do BigQuery.
Balanceamento de carga	Vários assinantes podem fazer chamadas de pull para a mesma assinatura "compartilhada". Cada assinante recebe um subconjunto das mensagens.	O ponto de extremidade de push pode ser um balanceador de carga.	O serviço do 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 estar acessíveis com nomes DNS e ter certificados SSL instalados.	É necessário que haja uma tabela do BigQuery para a assinatura de 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 lidar com o carregamento atual da mensagem transmitindo um erro 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	Consegue alta capacidade de processamento com pouca CPU e largura de banda. Para isso, permite a entrega e a confirmação em lote, assim como o consumo massivamente paralelo. Isso 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 da assinatura padrão

Por padrão, o Pub/Sub oferece entrega pelo menos uma vez, sem garantias de ordem 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 ordem de mensagens. Depois de definir a propriedade de ordenação de mensagens, o serviço Pub/Sub entrega as mensagens com a mesma chave de ordem e na ordem em que ela recebe.

O Pub/Sub também oferece suporte à entrega única.

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. O Pub/Sub pode enviar uma mensagem novamente mesmo depois que uma solicitação de confirmação for retornada com sucesso. Esse reenvio pode ser causado por problemas como reinicializações do lado do servidor ou problemas no lado do cliente. Assim, embora seja raro, qualquer mensagem pode ser reenviada a qualquer momento. Acomodação da entrega mais de uma vez exige que o assinante seja idempotente ao processar mensagens.

Vencimento da assinatura

Por padrão, as assinaturas expiram após 31 dias de inatividade do assinante ou se não houver atualizações na assinatura. Exemplos de atividades do 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 da assinatura será reiniciado. Usando políticas de expiração de assinatura, é possível configurar a duração da inatividade ou tornar a assinatura 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 tenha muitas mensagens não confirmadas, uma nova assinatura criada com o mesmo nome não terá um backlog (nenhuma mensagem aguardando entrega) no momento em que for criada.

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

A seguir

• Saiba mais sobre assinaturas pull.
• Saiba mais sobre as assinaturas push.
• Saiba mais sobre as assinaturas do BigQuery.