Quiz de Conceitos de RabbitMQ

Quiz de Conceitos de RabbitMQ

Teste seu entendimento sobre exchanges, routing keys e filas no RabbitMQ.

1. 1. O que é o RabbitMQ?

   • Um sistema de gerenciamento de banco de dados relacional
   • Um message broker AMQP de código aberto
   • Um gateway de API REST
   • Um armazenamento chave-valor distribuído

2. 2. Em um fluxo de mensagens típico do RabbitMQ, qual é a ordem correta dos componentes?

   • Consumidor → Fila → Exchange → Produtor
   • Produtor → Fila → Exchange → Consumidor
   • Produtor → Exchange → Fila → Consumidor
   • Exchange → Produtor → Fila → Consumidor

3. 3. O que é uma binding (ligação) no RabbitMQ?

   • Uma conexão TCP entre dois brokers
   • Uma regra que vincula uma exchange a uma fila (ou a outra exchange)
   • A credencial de autenticação utilizada por um produtor
   • Uma referência nomeada para um virtual host

4. 4. Qual é a exchange padrão (default exchange) no RabbitMQ?

   • Uma exchange fanout chamada 'default'
   • Uma exchange direct pré-declarada com nome de string vazia
   • Uma exchange topic chamada 'amq.default'
   • Uma exchange headers que precisa ser declarada antes do uso

5. 5. Qual é a diferença entre uma fila durável (durable) e uma fila transitória (transient)?

   • Filas duráveis sobrevivem a reinicializações do broker; filas transitórias não
   • Filas duráveis são mais rápidas; filas transitórias são mais lentas
   • Filas duráveis comportam mais mensagens do que filas transitórias
   • Filas duráveis exigem autenticação; filas transitórias não

6. 6. O que um consumidor envia ao RabbitMQ para confirmar que processou uma mensagem com sucesso?

   • Um NACK
   • Um REJECT
   • Um ACK (acknowledgement)
   • Um CONFIRM

7. 7. Qual é a diferença entre basic.nack e basic.reject no RabbitMQ?

   • basic.nack suporta rejeição em lote de múltiplas mensagens; basic.reject trata apenas uma mensagem por vez
   • basic.reject reenfileira a mensagem; basic.nack a descarta permanentemente
   • basic.nack está disponível apenas no AMQP 1.0; basic.reject pertence ao AMQP 0-9-1
   • Não há diferença funcional

8. 8. Qual plugin nativo do RabbitMQ fornece um painel de gerenciamento e monitoramento no navegador?

   • rabbitmq_shovel
   • rabbitmq_management
   • rabbitmq_federation
   • rabbitmq_stomp

9. 9. O que a configuração de prefetch count (basic.qos) controla no RabbitMQ?

   • O número máximo de filas que um canal pode assinar
   • O número máximo de mensagens não confirmadas entregues a um consumidor por vez
   • O tamanho máximo da mensagem em bytes
   • O número máximo de conexões por virtual host

10. 10. Por que o RabbitMQ geralmente é preferido em relação a um banco de dados relacional para fluxos de fila de tarefas?

    • O RabbitMQ armazena mensagens em tabelas SQL facilitando consultas
    • O RabbitMQ oferece entrega nativa por push, confirmações e back-pressure sem polling
    • Um banco de dados não consegue persistir dados após reinicializações
    • O RabbitMQ gera esquemas SQL automaticamente para metadados de tarefas

11. 11. Como uma exchange direct roteia mensagens?

    • Ela transmite a mensagem para todas as filas vinculadas, independentemente da routing key
    • Ela roteia a mensagem para filas cuja binding key corresponda exatamente à routing key da mensagem
    • Ela utiliza atributos do cabeçalho da mensagem para decidir o roteamento
    • Ela roteia com base em padrões de caracteres coringa na binding key

12. 12. Qual é o comportamento definidor de uma exchange fanout?

    • Ela roteia mensagens apenas para filas cuja binding key corresponda à routing key
    • Ela transmite toda mensagem para todas as filas vinculadas, ignorando completamente a routing key
    • Ela roteia mensagens usando padrões coringa (* e #)
    • Ela envia mensagens apenas para filas no mesmo nó

13. 13. Na binding key de uma topic exchange, o que o caractere coringa '#' casa?

    • Exatamente uma palavra separada por ponto
    • Qualquer caractere individual
    • Zero ou mais palavras separadas por ponto
    • Apenas caracteres numéricos

14. 14. Como uma headers exchange decide quais filas recebem uma mensagem?

    • Ela compara a routing key da mensagem com coringas presentes na binding key
    • Ela ignora completamente as routing keys e roteia com base em atributos do cabeçalho da mensagem que correspondam aos argumentos da binding
    • Ela distribui as mensagens em round-robin entre todas as filas vinculadas
    • Ela roteia com base no tipo de conteúdo (content-type) do corpo da mensagem

15. 15. Qual é a diferença conceitual entre uma routing key e uma binding key no RabbitMQ?

    • Elas são idênticas: ambos os termos referem-se à mesma string definida pelo produtor
    • A routing key é definida pelo produtor na mensagem; a binding key é definida quando uma fila é vinculada a uma exchange
    • A binding key é definida pelo produtor; a routing key é definida na fila
    • Routing keys são usadas apenas por direct exchanges; binding keys são usadas apenas por topic exchanges

16. 16. Como uma Dead Letter Exchange (DLX) é configurada em uma fila?

    • Definindo o argumento 'x-dead-letter-exchange' ao declarar a fila
    • Publicando diretamente em uma exchange chamada 'dlx'
    • Ativando o plugin rabbitmq_dlx
    • Definindo a propriedade 'dead-letter' em cada mensagem individualmente

17. 17. Qual é a diferença entre definir o TTL da mensagem por fila versus por mensagem?

    • O TTL por fila aplica-se a todas as mensagens da fila via x-message-ttl; o TTL por mensagem é definido na propriedade expiration da mensagem e pode variar a cada uma
    • O TTL por mensagem sempre tem maior prioridade e substitui qualquer TTL da fila
    • O TTL por fila requer um plugin; o TTL por mensagem é nativo
    • Não há diferença: ambos provocam comportamento idêntico no broker

18. 18. Qual é a principal vantagem dos publisher confirms em comparação com transações AMQP (tx.select/tx.commit) no RabbitMQ?

    • Publisher confirms são síncronos e bloqueiam o canal até que o broker confirme
    • Publisher confirms fornecem confirmação assíncrona e leve sem a pesada sobrecarga de two-phase commit das transações
    • Transações AMQP suportam confirmações em lote; publisher confirms não suportam
    • Publisher confirms estão disponíveis apenas para quorum queues

19. 19. Qual é a finalidade principal do plugin Shovel do RabbitMQ?

    • Espelhar filas entre nós do cluster para alta disponibilidade
    • Mover ou copiar mensagens de forma confiável de uma fila/exchange de origem para uma fila/exchange de destino, inclusive entre brokers diferentes
    • Expor filas através de uma API REST HTTP
    • Comprimir o payload das mensagens antes do armazenamento

20. 20. Qual é a principal diferença arquitetural entre quorum queues e classic mirrored queues?

    • Quorum queues usam o algoritmo de consenso Raft para replicação; classic mirrored queues usavam replicação assíncrona mestre-espelho
    • Classic mirrored queues são mais rápidas porque usam Raft; quorum queues usam two-phase commit
    • Quorum queues só podem existir em um único nó; mirrored queues abrangem todo o cluster
    • Não há diferença: quorum queues são apenas o novo nome das mirrored queues

21. 21. Como o AMQP 0-9-1 viabiliza múltiplos fluxos lógicos de comunicação sobre uma única conexão TCP no RabbitMQ?

    • Abrindo múltiplos sockets TCP agrupados em um único objeto de conexão
    • Por meio de canais: conexões virtuais leves multiplexadas sobre uma única conexão TCP
    • Utilizando multiplexação de streams HTTP/2 dentro do framing do AMQP
    • Codificando cada fluxo lógico como um virtual host separado

22. 22. O que o mecanismo channel.flow do AMQP 0-9-1 faz?

    • Ele aumenta a janela de prefetch dinamicamente quando o consumidor está ocioso
    • Ele permite ao broker ou ao cliente pausar/retomar a entrega de mensagens em um canal para exercer back-pressure
    • Ele migra um canal de uma conexão TCP para outra sem interrupção
    • Ele descarrega em disco todas as mensagens pendentes do buffer interno de um canal

23. 23. Qual é o principal benefício operacional de declarar uma fila como lazy queue?

    • Lazy queues ignoram o processamento de confirmações (ACKs) para elevar a vazão
    • Lazy queues gravam mensagens diretamente em disco assim que chegam em vez de mantê-las na memória, reduzindo o consumo de RAM em filas grandes
    • Lazy queues replicam em disco apenas quando o nó reinicia
    • Lazy queues adiam a avaliação de bindings até que um consumidor se conecte

24. 24. Qual é a principal diferença arquitetural entre o plugin Federation e o plugin Shovel?

    • Links do Federation são permanentes; links do Shovel são temporários e se autoexcluem após uma única mensagem
    • O Federation oferece vinculação fracamente acoplada de exchange/fila entre brokers com nós autônomos; o Shovel é um transportador simples ponto a ponto de mensagens que exige acoplamento direto
    • O Shovel suporta AMQP 1.0; o Federation suporta apenas AMQP 0-9-1
    • Eles são funcionalmente idênticos: Federation é apenas o nome mais novo do Shovel

25. 25. O que o plugin consistent hash exchange realiza que uma exchange direct ou topic padrão não consegue?

    • Ele roteia mensagens para exatamente uma fila escolhida por hash consistente da routing key, distribuindo a carga enquanto mantém mensagens com a mesma chave na mesma fila
    • Ele replica mensagens para todas as filas vinculadas usando um mecanismo de desduplicação baseado em hash
    • Ele calcula o hash do corpo da mensagem para verificar a integridade antes do roteamento
    • Ele garante a entrega em round-robin entre as filas, independentemente da routing key

26. 26. Em um cluster RabbitMQ, qual é a diferença funcional entre nós de disco (disc nodes) e nós de memória (RAM nodes)?

    • Nós de disco persistem metadados do broker (filas, exchanges, bindings, usuários) no disco; nós de RAM mantêm os metadados apenas na memória para gravações com menor latência
    • Nós de RAM cuidam do roteamento de mensagens; nós de disco cuidam apenas do armazenamento persistente de mensagens
    • Nós de disco podem hospedar quorum queues; nós de RAM não podem
    • Os termos estão em desuso: todos os nós modernos do RabbitMQ são idênticos

27. 27. Como as quorum queues utilizam o algoritmo de consenso Raft para garantir a segurança dos dados?

    • Uma mensagem só é considerada confirmada após ser gravada por uma maioria (quórum) de réplicas, assegurando ausência de perda de dados mesmo se uma minoria de nós falhar
    • O Raft é usado apenas para eleição de líder; o armazenamento de mensagens utiliza um protocolo separado de two-phase commit
    • Quorum queues gravam em todas as réplicas de forma síncrona e exigem confirmação unânime
    • O Raft assegura que as mensagens sejam desduplicadas em todos os nós do cluster

28. 28. Quando tanto uma política por fila quanto um argumento de declaração de fila (ex.: x-message-ttl) são configurados para a mesma chave, qual tem precedência no RabbitMQ?

    • Políticas sempre prevalecem sobre argumentos de declaração
    • Argumentos de declaração sempre perdem para políticas
    • Argumentos de declaração (definidos na criação da fila) têm precedência sobre políticas para a mesma chave
    • Ambos são combinados cumulativamente: nenhum sobrepõe o outro

29. 29. Qual par de métricas de gerenciamento do RabbitMQ indica mais diretamente que os consumidores estão ficando para trás em relação aos produtores?

    • publish_rate e deliver_rate: quando publish_rate excede deliver_rate de forma constante, messages_ready aumentará
    • memory_used e disk_free: um aumento de memory_used com queda de disk_free indica atraso do consumidor
    • connection_count e channel_count: excesso de canais indica acúmulo de trabalho nos consumidores
    • node_uptime e gc_reclaim_rate: alta atividade do coletor de lixo confirma atraso do consumidor

30. 30. Qual é a abordagem recomendada para o encerramento gracioso (graceful shutdown) de um consumidor no RabbitMQ para evitar perda de mensagens?

    • Encerrar o processo imediatamente: o RabbitMQ reenfileirará automaticamente qualquer mensagem sem confirmação
    • Cancelar a assinatura do consumidor, terminar o processamento de todas as mensagens em andamento, enviar ACKs ou NACKs para cada uma e fechar o canal e a conexão
    • Chamar basic.reject em todas as mensagens e encerrar a conexão TCP sem enviar o frame connection.close
    • Definir prefetch para 0 e aguardar o broker esvaziar a fila antes do encerramento