Visão geral da assinatura

Para receber as mensagens publicadas em um tópico, você precisa se inscrever nele tópico. Somente mensagens publicadas no tópico após a criação da assinatura estão disponíveis para os clientes assinantes. O cliente assinante recebe e processa as mensagens publicadas no tópico. Um tópico pode ter várias assinaturas, mas cada assinatura pertence a somente um tópico.

O recurso de retenção de tópicos permite que uma assinatura anexada a um tópico volte no tempo e reproduza mensagens publicadas anteriormente. Saiba mais sobre o recurso no tópico Como repetir e limpar mensagens.

Fluxo de trabalho de assinatura

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

  2. Se uma mensagem foi enviada para entrega e um assinante ainda não confirmou a mensagem será chamada de pendente.

  3. O Pub/Sub tenta repetidamente entregar qualquer mensagem que esteja ainda não confirmados. No entanto, o Pub/Sub tenta não entregar uma mensagem pendente a qualquer outro assinante da mesma assinatura.

  4. O assinante tem um limite de tempo configurável, conhecido como o ackDeadline para confirmar a mensagem pendente. Após o prazo passar, a mensagem não será mais considerada pendente, e O Pub/Sub tenta reenviar a mensagem.

Tipos de assinatura

Ao criar uma assinatura, você precisa especificar o tipo de entrega da mensagem. O Pub/Sub oferece os seguintes tipos de assinaturas:

  • As assinaturas pull usam um cliente assinante para solicitar mensagens servidor do Pub/Sub.

  • As inscrições push usam o servidor Pub/Sub para iniciar solicitações ao aplicativo assinante para entregar mensagens.

  • As assinaturas de exportação ajudam você a exportar suas mensagens diretamente para um recurso do Google Cloud. Essas assinaturas incluem o seguinte:

    • As assinaturas do BigQuery exportam dados para um Tabela do BigQuery.

    • As assinaturas do Cloud Storage exportam dados para um bucket do Cloud Storage.

Para escolher a assinatura ideal para seus requisitos de negócios, consulte Escolha um tipo de assinatura. Você pode atualizar o tipo de entrega de mensagem para uma assinatura a qualquer momento após sua criação.

Propriedades padrão da assinatura

Por padrão, o Pub/Sub oferece a 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 ordenação 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 aceita entrega única.

Em geral, o Pub/Sub entrega cada mensagem uma vez e na ordem em que foi publicada. Mas, às vezes, as mensagens podem ser entregues ou mais de uma vez. O Pub/Sub pode entregar novamente uma mensagem depois que uma solicitação de confirmação da mensagem for retornada com sucesso. Isso o reenvio pode ser causado por problemas como reinicializações do lado do servidor ou problemas. Assim, embora seja raro, qualquer mensagem pode ser entregue a qualquer momento.

Para acomodar mais de uma entrega, o assinante precisa ser idempotente ao processar mensagens.

Validade da assinatura

Por padrão, as assinaturas expiram após 31 dias de inatividade ou se que nenhuma atualização seja feita nela. Exemplos de atividades de inscritos incluem conexões abertas, pulls ativos ou pushes bem-sucedidos. Se O Pub/Sub detecta a atividade do assinante ou uma atualização do propriedades da assinatura, o relógio de exclusão da assinatura será reiniciado. Usando de expiração da assinatura, você pode configurar a duração da inatividade ou tornar a assinatura persistente independentemente da atividade. Você também pode 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 se a versão tiver sido excluída tinha muitas mensagens não confirmadas, uma nova assinatura foi criada com mesmo nome não teriam backlog (nenhuma mensagem aguardando entrega) no momento em que é criado.

A seguir