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 essenciais, que são explicados com a ajuda da figura a seguir.

Confira 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 rege 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 de uma assinatura específica.

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

1. Dois aplicativos editores, Publisher 1 e Publisher 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. São elas 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 assinantes 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 aplicativo de assinante chamado assinante 3. Assim, o assinante 3 recebe todas as mensagens do tópico.

Ciclo de vida 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.

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

1. Um aplicativo 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 ao tópico.

   Neste exemplo, é uma única assinatura.

4. A assinatura envia a mensagem para um aplicativo de 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 a excluirá do armazenamento.

Status de uma mensagem no Pub/Sub

No entanto, enquanto houver alguma mensagem 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. 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 Pub/Sub pode ter três estados:

• Mensagens confirmadas. Depois que um aplicativo 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, 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 expire desde a publicação. Nesse ponto, a mensagem expira.

• Mensagens com confirmação negativa (nacked). O NACK de uma mensagem por um assinante faz com que o Pub/Sub a reenvie imediatamente com base nas configurações de nova tentativa padrão, que podem ser modificadas. Quando um assinante envia NACKs para mensagens inválidas ou não consegue processá-las, ele ajuda a garantir que elas não sejam perdidas e que sejam processadas corretamente. É possível usar modifyAckDeadline com um valor de 0 para enviar um NACK a uma mensagem.

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

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

Alguns dos padrões de publicação/assinatura do Pub/Sub compatíveis incluem:

• Um único destino (muitos para um). Neste exemplo, vários aplicativos de editores publicam mensagens em um único tópico. Esse único tópico está anexado a uma única assinatura. A assinatura, por sua vez, é conectada a um único aplicativo de 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 é vinculado a uma única assinatura que, por sua vez, está conectada a vários aplicativos de assinante. Cada um dos aplicativos assinantes recebe um subconjunto das mensagens publicadas, e não há dois aplicativos assinantes que recebem 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 ser compatíveis, adicione mais assinantes para receber mensagens da mesma assinatura.

• Vários destinos (um para muitos). Neste exemplo, um ou vários aplicativos de publicação 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 assinantes 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 diferentes operações de dados no mesmo conjunto de mensagens, o fan-out será uma boa opção. Também é possível anexar vários assinantes a cada assinatura e receber um subconjunto de mensagens com balanceamento de 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 doCloud de Confiance
• CLI do Google Cloud
• 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 seu caso de uso.

Se você não conhece o console do Cloud de Confiance 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 pré-criadas 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.

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

• Para usar diretamente as bibliotecas de cliente de baixo nível geradas automaticamente, consulte Visão geral das APIs Pub/Sub.

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

• Escolha a linguagem certa da biblioteca de cliente. A performance das bibliotecas de cliente do Pub/Sub varia de acordo com a linguagem. Por exemplo, a biblioteca de cliente Java é mais eficaz no escalonamento vertical do que a biblioteca de cliente Python e pode processar mais capacidade. Java, C++ e Go são linguagens mais eficientes em termos de recursos de computação necessários para lidar com as cargas de publicação ou inscrição.

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

• Reutilizar clientes do editor. Ao publicar mensagens, é mais eficiente reutilizar o mesmo cliente editor em vez de criar novos clientes para cada solicitação de publicação. Isso acontece porque a primeira solicitação de publicação depois de criar um novo cliente publisher leva algum tempo para estabelecer uma conexão autorizada. Em algumas linguagens, 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 de 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 Cloud de Confiance em que você possa configurar o Pub/Sub.

2. Ative a API Pub/Sub.

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

4. Crie um tópico.

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

6. Anexe o esquema ao tópico.

7. Configure um cliente 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 em 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 concessã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, uma assinatura, um esquema ou um 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 snapshot. O nome do recurso precisa obedecer ao seguinte formato:

projects/project-identifier/collection/ID

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

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

• ID: precisa obedecer às 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 ., indicadores diacríticos ~, indicadores de adição + e símbolos de porcentagem %.

  É possível usar os caracteres especiais na lista anterior em nomes de recursos sem codificação para URLs. Mas, é preciso garantir que os demais 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

• Para começar a configurar o Pub/Sub usando a CLI gcloud, consulte Guia de início rápido: publicar e receber mensagens no Pub/Sub usando a CLI gcloud.

• Para começar a configurar o Pub/Sub usando o console Cloud de Confiance , consulte Guia de início rápido: publicar e receber mensagens no Pub/Sub usando o console Cloud de Confiance .

• Para começar a configurar o Pub/Sub usando as bibliotecas de cliente, consulte Guia de início rápido: publicar e receber mensagens no Pub/Sub usando a biblioteca de cliente.