Questão de Arquitetura de Computadores — Barramento — FGV 2024
Arquitetura de Computadores›Barramento
Código
fg086698
Banca
FGV
Órgão
MF
Ano
2024
Nível
Superior
Cargo
Auditor Federal de Finanças e Controle - Área de Tecnologia da Informação (Operação e Infraestrutura) - manhã
O padrão Publish/Subscribe é comumente utilizado em sistemas de computação distribuídos e em arquiteturas de barramento de mensagem.Uma característica desse padrão é que o produtor de eventos deve
Aaguardar acumular ao menos 10 eventos antes de começar a enviá-los.
Benviar eventos somente quando o consumidor de eventos solicitar.
Caguardar uma confirmação do consumidor de eventos para enviar eventos adicionais.
Denviar os eventos independentemente da quantidade de consumidores de eventos.
Eespecificar como o consumidor de eventos deve agir para processar o evento.
Revelar gabarito e comentário▾
GabaritoD — enviar os eventos independentemente da quantidade de consumidores de eventos.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Publish/Subscribe (Pub/Sub) – Características
Gabarito: letra D. No padrão Publish/Subscribe, o produtor (publisher) envia eventos para um tópico sem necessidade de conhecer os consumidores (subscribers). Portanto, ele envia os eventos independentemente da quantidade de consumidores. As demais alternativas confundem o padrão com outros mecanismos de comunicação.
Alternativa A — ❌ Incorreta
A afirmação de que o produtor deve aguardar acumular ao menos 10 eventos não é característica do Pub/Sub. O produtor pode publicar imediatamente cada evento, sem batching obrigatório.
Alternativa B — ❌ Incorreta
No padrão Pub/Sub, o produtor envia eventos por iniciativa própria (push), e não aguarda solicitação do consumidor. A descrição remete ao padrão request-response ou polling.
Alternativa C — ❌ Incorreta
O Pub/Sub é assíncrono; não exige confirmação do consumidor para enviar novos eventos. Isso seria um handshake síncrono, típico de outros protocolos.
Alternativa D — ✅ Correta ⟵ GABARITO
Correta. O produtor publica eventos no barramento/tópico, e os consumidores interessados os recebem. O produtor não depende do número de consumidores.
Alternativa E — ❌ Incorreta
O produtor não especifica como o consumidor deve processar o evento. Cada consumidor trata o evento de acordo com sua lógica.
PEGA ESSA DICA!
Lembre-se: Pub/Sub é push (publicação ativa), assíncrono e desacoplado. O produtor não precisa saber quem são os consumidores nem quantos são.