zanarelliandGitHub
c8423198cd
Add Brazilian Portuguese (pt) translations for three previously untranslated pattern READMEs, following the existing localization/pt/ convention documented in the wiki (15. Support for multiple languages). Frontmatter and section headers follow the same structure used by the most recently updated existing translation (singleton), keeping code blocks, links, and image references unchanged from the English source.
title, shortTitle, description, category, language, tag
| title | shortTitle | description | category | language | tag | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| Polling Publisher-Subscriber Pattern in Java: Mastering Asynchronous Messaging Elegantly | Polling Pub/Sub | Learn how to implement a Polling Publisher-Subscriber system in Java using Spring Boot and Kafka. Explore the architecture, real-world analogies, and benefits of asynchronous communication with clean code examples. | Architectural | pt |
|
Também conhecido como
- Event-Driven Architecture
- Asynchronous Pub/Sub Pattern
- Message Queue-Based Polling System
Propósito
O padrão Polling Publisher-Subscriber desacopla os produtores de dados dos consumidores ao permitir uma comunicação assíncrona e orientada a mensagens. Um serviço consulta periodicamente (poll) uma fonte de dados e publica mensagens em um message broker (por exemplo, Kafka), que são então consumidas por um ou mais serviços assinantes.
Explicação
Exemplo do mundo real
Uma agência de notícias consulta constantemente as últimas atualizações. Assim que recebe novas informações, ela as publica em diferentes veículos (TV, jornais, aplicativos). Cada veículo consome e exibe as atualizações de forma independente.
Em outras palavras
Um serviço verifica regularmente se há atualizações (polling) e envia mensagens para o Kafka. Outro serviço escuta o Kafka e processa as mensagens de forma assíncrona.
De acordo com a Wikipédia
Este padrão se assemelha muito ao modelo Publish–subscribe, no qual as mensagens são enviadas pelos publicadores e recebidas pelos assinantes sem que eles se conheçam.
Fluxo da arquitetura
+------------+ +--------+ +-------------+
| Publisher | ---> | Kafka | ---> | Subscriber |
+------------+ +--------+ +-------------+
Exemplo Programático (Spring Boot + Kafka)
Serviço Publisher
- Usa o
@Scheduleddo Spring para consultar dados periodicamente. - Publica dados em um tópico do Kafka.
- Opcionalmente expõe uma API REST para publicação manual de dados.
@Scheduled(fixedRate = 5000)
public void pollAndPublish() {
String data = pollingService.getLatestData();
kafkaTemplate.send("updates-topic", data);
}
Serviço Subscriber
- Escuta um tópico do Kafka usando
@KafkaListener. - Processa as mensagens de forma assíncrona.
@KafkaListener(topics = "updates-topic")
public void processUpdate(String message) {
log.info("Received update: {}", message);
updateProcessor.handle(message);
}
Quando usar o padrão Polling Publisher-Subscriber
Use esse padrão quando:
- Não é possível o produtor enviar dados em tempo real (push).
- Deseja-se um baixo acoplamento entre produtores e consumidores.
- É necessário processamento de eventos assíncrono e escalável.
- Você está construindo uma arquitetura de microsserviços orientada a eventos.
Aplicações do mundo real
- Painéis de relatórios em tempo real
- Agregadores de health check para sistemas distribuídos
- Processamento de telemetria de IoT
- Sistemas de notificação e alerta
Benefícios e desafios do padrão Polling Pub/Sub
Benefícios
- Baixo acoplamento entre serviços
- Arquitetura assíncrona e escalável
- Tolerante a falhas, com persistência de mensagens no Kafka
- Fácil de estender com novos consumidores ou publicadores
Desafios
- O polling introduz latência entre a geração e o consumo dos dados
- Requer o gerenciamento e a configuração do Kafka (ou de outro broker)
- Implantação e infraestrutura ligeiramente mais complexas