Visão geral do serviço do Pub/Sub

O Pub/Sub é um serviço de publicação/assinatura (Pub/Sub) , um serviço de mensagens em que os remetentes são dissociados dos destinatários. Um serviço do Pub/Sub tem vários conceitos-chave, que são explicados com a ajuda da figura a seguir.

Figura mostrando diferentes componentes de um serviço do Pub/Sub e como eles se conectam entre si.
Figura 1 Dois clientes de publicação enviam duas mensagens diferentes para um tópico comum do Pub/Sub.

Confira a seguir os componentes de um serviço do Pub/Sub:

  • Editor (também chamado de produtor): cria mensagens e as envia (publica) para o serviço de mensagens em um tópico específico.

  • Mensagem: os dados transferidos por meio do serviço.

  • Tópico: uma entidade nomeada que representa um feed de mensagens.

  • Esquema: uma entidade nomeada que governa o formato de dados de uma mensagem do Pub/Sub.

  • Assinatura: uma entidade nomeada que representa um interesse em receber mensagens sobre um tópico específico.

  • Assinante (também chamado de consumidor): recebe mensagens em uma assinatura especificada.

O procedimento a seguir discute o fluxo de trabalho do serviço Pub/Sub:

  1. Dois aplicativos de editor, Editor 1 e Editor 2, enviam mensagens para um único tópico do Pub/Sub. O Editor 1 envia a mensagem A, e o Editor 2 envia a mensagem B.

  2. O tópico está anexado a duas assinaturas. Elas são Assinatura 1 e Assinatura 2.

  3. O tópico também é anexado a um esquema.

  4. Cada assinatura recebe uma cópia das mensagens A e B do tópico.

  5. A assinatura 1 está conectada a dois aplicativos de assinante, Assinante 1 e Assinante 2. Os dois aplicativos do assinante recebem um subconjunto das mensagens do tópico. Neste exemplo, o Assinante 1 recebe a mensagem B, enquanto o Assinante 2 recebe a mensagem A do tópico.

  6. A assinatura 2 está conectada apenas a um único aplicativo de assinante chamado Assinante 3. Assim, o Assinante 3 recebe todas as mensagens do tópico.

Vida útil de uma mensagem

Suponha que um único cliente editor esteja conectado a um tópico. O tópico tem uma única assinatura anexada. Um único assinante está conectado à assinatura.

Figura mostrando como uma mensagem flui no Pub/Sub.
Figura 2 Uma mensagem flui de um cliente editor para um cliente assinante pelo Pub/Sub.

As etapas a seguir descrevem como uma mensagem flui no Pub/Sub:

  1. Um aplicativo de editor envia uma mensagem para um tópico do Pub/Sub.

  2. A mensagem é gravada no armazenamento.

  3. Além de gravar a mensagem no armazenamento, o Pub/Sub a entrega a todas as assinaturas anexadas do tópico.

    Neste exemplo, é uma única assinatura.

  4. A assinatura envia a mensagem para um aplicativo do assinante anexado.

  5. O assinante envia uma confirmação ao Pub/Sub de que processou a mensagem.

    Depois que pelo menos um assinante de cada assinatura reconhecer a mensagem, o Pub/Sub vai excluir a mensagem do armazenamento.

Status de uma mensagem no Pub/Sub

Enquanto uma mensagem estiver pendente para um assinante, o Pub/Sub não tentará entregá-la a nenhum outro assinante na mesma assinatura. O assinante tem um período de tempo limitado para confirmar a mensagem, que pode ser configurado e é chamado de ackDeadline, para confirmar a mensagem pendente. Depois que o prazo termina, a mensagem não é mais considerada pendente e fica disponível para entrega novamente.

Uma mensagem em um serviço do Pub/Sub pode ter três estados:

  • Mensagens confirmadas (confirmadas). Depois que um aplicativo de assinante processa uma mensagem enviada de um tópico para uma assinatura, ele envia uma confirmação de volta ao Pub/Sub. Se todas as assinaturas de um tópico confirmarem o recebimento da mensagem, ela será excluída de modo assíncrono da origem de mensagens publicadas e do armazenamento.

  • Mensagens não confirmadas (unacked). Se o Pub/Sub não receber uma confirmação dentro do prazo de confirmação, uma mensagem poderá ser entregue mais de uma vez. Por exemplo, o assinante pode enviar uma confirmação após o prazo expirar ou a confirmação pode ser perdida devido a problemas temporários de rede. Uma mensagem não confirmada continua sendo entregue até que a duração da retenção da mensagem expire desde a publicação. Nesse ponto, a mensagem expira.

  • Mensagens com resposta negativa (nacked). Quando um assinante faz um nack de uma mensagem, o Pub/Sub a entrega novamente imediatamente. Quando um assinante rejeita mensagens inválidas ou não consegue processá-las, ele ajuda a garantir que essas mensagens não se percam e que sejam processadas com sucesso. Você pode usar modifyAckDeadline com um valor de 0 para negar uma mensagem.

Escolher um padrão de publicação e assinatura do Pub/Sub

Quando há vários clientes de editor e assinante do Pub/Sub, também é necessário escolher o tipo de arquitetura de publicação e assinatura que você quer configurar.

Figura mostrando diferentes padrões de publicação e inscrição.
Figura 3 As relações entre editor e assinante podem ser de muitos para um (fan-in), de muitos para muitos (balanceamento de carga) e de um para muitos (fan-out).

Alguns dos padrões de publicação/assinatura do Pub/Sub com suporte incluem:

  • Ventilador para dentro (muitos para um). Neste exemplo, vários aplicativos de editor publicam mensagens em um único tópico. Esse único tópico é anexado a uma única assinatura. A assinatura é conectada a um único aplicativo do assinante, que recebe todas as mensagens publicadas no tópico.

  • Balanceado por carga (muitos para muitos). Neste exemplo, um ou vários aplicativos de editor publicam mensagens em um único tópico. Esse único tópico é anexado a uma única assinatura que, por sua vez, está conectada a vários aplicativos de assinantes. Cada um dos aplicativos do assinante recebe um subconjunto das mensagens publicadas, e nenhum dos dois aplicativos do assinante recebe o mesmo subconjunto de mensagens. Nesse caso de balanceamento de carga, você usa vários assinantes para processar mensagens em grande escala. Se mais mensagens precisarem de suporte, adicione mais assinantes para receber mensagens da mesma assinatura.

  • Divisão (um para muitos). Neste exemplo, um ou vários aplicativos de editor publicam mensagens em um único tópico. Esse único tópico está anexado a várias assinaturas. Cada assinatura está conectada a um único aplicativo de assinante. Cada um dos aplicativos de assinante recebe o mesmo conjunto de mensagens publicadas do tópico. Quando um tópico tem várias assinaturas, cada mensagem precisa ser enviada a um assinante que recebe mensagens em nome de cada assinatura. Se você precisar realizar operações de dados diferentes no mesmo conjunto de mensagens, a expansão é uma boa opção. Também é possível anexar vários assinantes a cada assinatura e receber um subconjunto de mensagens balanceado por carga para cada assinante.

Escolher uma opção de configuração do Pub/Sub

É possível configurar um ambiente do Pub/Sub usando uma das seguintes opções:

  • Console do Google Cloud
  • Google Cloud CLI
  • Bibliotecas de cliente do Cloud (biblioteca de cliente de alto nível)
  • APIs REST e RPC (biblioteca de cliente de baixo nível)

A escolha de uma opção de configuração do Pub/Sub depende do caso de uso.

Se você não conhece o console do Google Cloud e quer testar o Pub/Sub, use o console ou o gcloud CLI.

A biblioteca de cliente de alto nível é recomendada para casos em que você precisa de alta capacidade de processamento e baixa latência com sobrecarga operacional e custo de processamento mínimos. Por padrão, a biblioteca de cliente de alto nível usa a API StreamingPull. As bibliotecas de cliente de alto nível contêm funções e classes predefinidas que processam as chamadas de API subjacentes para autenticação, otimização de taxa de transferência e latência, formatação de mensagens e outros recursos.

A biblioteca de cliente de baixo nível é uma biblioteca gRPC gerada automaticamente e entra em ação quando você usa as APIs de serviço diretamente.

Confira algumas práticas recomendadas para usar as bibliotecas de cliente:

  • Escolha a linguagem certa para a biblioteca de cliente. O desempenho das bibliotecas de cliente do Pub/Sub varia de acordo com o idioma. Por exemplo, a biblioteca de cliente Java é mais eficaz na expansão vertical do que a biblioteca de cliente Python e pode lidar com mais throughput. Java, C++ e Go são linguagens mais eficientes em termos de recursos de computação necessários para processar as cargas de publicação ou assinatura.

  • Use a versão mais recente da biblioteca de cliente. As bibliotecas de cliente do Pub/Sub são constantemente atualizadas com novos recursos e correções de bugs. Verifique se você está usando a versão mais recente da biblioteca de cliente para seu idioma.

  • Reutilizar clientes do editor. Ao publicar mensagens, é mais eficiente reutilizar o mesmo cliente de publicação em vez de criar novos clientes para cada solicitação de publicação. Isso ocorre porque a primeira solicitação de publicação após a criação de um novo cliente de publisher requer algum tempo para estabelecer uma conexão autorizada. Em alguns idiomas, como o Node, que não têm um cliente de editor explícito, reutilize o objeto em que você chama o método de publicação. Por exemplo, no Node, salve e reutilize o objeto do tópico.

Como configurar o Pub/Sub

Estas são as etapas de nível superior para configurar o Pub/Sub:

  1. Crie ou escolha um projeto do Google Cloud em que você possa configurar o Pub/Sub.

  2. Ative a API Pub/Sub.

  3. Receba os papéis e as permissões necessárias para executar o Pub/Sub.

  4. Crie um tópico.

  5. Se a estrutura da mensagem for essencial, defina um esquema para ela.

  6. Anexe o esquema ao tópico.

  7. Configure um cliente do editor que possa publicar mensagens no tópico.

  8. Se necessário, configure opções avançadas de publicação, como controle de fluxo, mensagens em lote e controle de simultaneidade.

  9. Escolha um tipo de assinatura com base na forma como você quer receber mensagens.

  10. Crie uma assinatura para o tópico escolhido.

  11. Configure um cliente assinante que possa receber mensagens da assinatura.

  12. Se necessário, configure opções avançadas de entrega de mensagens, como entrega exatamente uma vez, gerenciamento de locação, entrega ordenada e controle de fluxo.

  13. Comece a publicar mensagens do cliente editor no tópico.

  14. Ao mesmo tempo, configure o cliente assinante para receber e processar essas mensagens.

Diretrizes para nomear um tópico, assinatura, esquema ou snapshot

Um nome de recurso do Pub/Sub identifica exclusivamente um recurso do Pub/Sub, como um tópico, uma assinatura, um esquema ou um instantâneo. O nome do recurso precisa ter o seguinte formato:

projects/project-identifier/collection/ID

  • project-identifier: precisa ser o ID ou número do projeto, disponível no console do Google Cloud. Por exemplo, my-cool-project é um ID do projeto. 123456789123 é um número de projeto.

  • collection: precisa ser topics, subscriptions, schemas ou snapshots.

  • ID: precisa estar em conformidade com as seguintes diretrizes:

    • não começar com a string goog;
    • Começar com uma letra
    • conter entre 3 e 255 caracteres;
    • Conter apenas os seguintes caracteres: letras [A-Za-z], números [0-9], traços -, sublinhados _, pontos ., til ~, sinais de soma + e símbolos de porcentagem %

    É possível usar os caracteres especiais na lista anterior em nomes de recursos sem codificação para URLs. No entanto, é preciso garantir que todos os outros caracteres especiais sejam codificados ou decodificados corretamente quando usados em URLs. Por exemplo, mi-tópico é um ID inválido. No entanto, mi-t%C3%B3pico é válido. Esse formato é importante quando você faz chamadas REST.

A seguir