Quiz de Conceptos de RabbitMQ

Quiz de Conceptos de RabbitMQ

Pon a prueba tu comprensión sobre exchanges, routing keys y colas en RabbitMQ.

1. 1. ¿Qué es RabbitMQ?

   • Un sistema de gestión de bases de datos relacionales
   • Un broker de mensajería AMQP de código abierto
   • Una pasarela de API REST
   • Un almacén clave-valor distribuido

2. 2. En un flujo típico de mensajes en RabbitMQ, ¿cuál es el orden correcto de los componentes?

   • Consumidor → Cola → Exchange → Productor
   • Productor → Cola → Exchange → Consumidor
   • Productor → Exchange → Cola → Consumidor
   • Exchange → Productor → Cola → Consumidor

3. 3. ¿Qué es un enlace (binding) en RabbitMQ?

   • Una conexión TCP entre dos brokers
   • Una regla que vincula una exchange con una cola (o con otra exchange)
   • La credencial de autenticación utilizada por un productor
   • Una referencia con nombre a un virtual host

4. 4. ¿Qué es la exchange predeterminada (default exchange) en RabbitMQ?

   • Una exchange fanout llamada 'default'
   • Una exchange direct predeclarada con nombre de cadena vacía
   • Una exchange topic llamada 'amq.default'
   • Una exchange headers que debe declararse antes de usarse

5. 5. ¿Cuál es la diferencia entre una cola durable y una cola transitoria (transient)?

   • Las colas durables sobreviven al reinicio del broker; las colas transitorias no
   • Las colas durables son más rápidas; las colas transitorias son más lentas
   • Las colas durables pueden contener más mensajes que las colas transitorias
   • Las colas durables requieren autenticación; las colas transitorias no

6. 6. ¿Qué envía un consumidor a RabbitMQ para confirmar que ha procesado un mensaje con éxito?

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

7. 7. ¿Cuál es la diferencia entre basic.nack y basic.reject en RabbitMQ?

   • basic.nack admite el rechazo por lotes de múltiples mensajes; basic.reject procesa solo un mensaje a la vez
   • basic.reject reencola el mensaje; basic.nack lo descarta permanentemente
   • basic.nack solo está disponible en AMQP 1.0; basic.reject es de AMQP 0-9-1
   • No existe ninguna diferencia funcional

8. 8. ¿Qué plugin nativo de RabbitMQ proporciona un panel de gestión y monitorización accesible desde el navegador?

   • rabbitmq_shovel
   • rabbitmq_management
   • rabbitmq_federation
   • rabbitmq_stomp

9. 9. ¿Qué controla el ajuste prefetch count (basic.qos) en RabbitMQ?

   • El número máximo de colas a las que un canal puede suscribirse
   • El número máximo de mensajes no confirmados entregados a un consumidor al mismo tiempo
   • El tamaño máximo del mensaje en bytes
   • El número máximo de conexiones por virtual host

10. 10. ¿Por qué suele preferirse RabbitMQ sobre una base de datos relacional para colas de tareas?

    • RabbitMQ almacena los mensajes en tablas SQL para facilitar consultas
    • RabbitMQ ofrece entrega nativa por push, confirmaciones y back-pressure sin sondeo (polling)
    • Una base de datos no puede persistir datos tras un reinicio
    • RabbitMQ genera esquemas SQL automáticamente para metadados de tareas

11. 11. ¿Cómo enruta mensajes una exchange de tipo direct?

    • Difunde el mensaje a todas las colas vinculadas independientemente de la routing key
    • Enruta el mensaje a las colas cuya binding key coincida con exactitud con la routing key del mensaje
    • Utiliza atributos de las cabeceras del mensaje para decidir el enrutamiento
    • Enruta basándose en patrones de comodines en la binding key

12. 12. ¿Cuál es el comportamiento distintivo de una exchange fanout?

    • Enruta mensajes únicamente a colas cuya binding key coincida con la routing key
    • Difunde cada mensaje a todas las colas vinculadas, ignorando totalmente la routing key
    • Enruta mensajes utilizando patrones con comodines (* y #)
    • Envía mensajes únicamente a colas ubicadas en el mismo nodo

13. 13. En la binding key de una exchange topic, ¿con qué coincide el comodín '#'?

    • Exactamente una palabra separada por puntos
    • Cualquier carácter individual
    • Cero o más palabras separadas por puntos
    • Únicamente caracteres numéricos

14. 14. ¿Cómo determina una headers exchange qué colas reciben un mensaje?

    • Compara la routing key del mensaje contra los comodines de la binding key
    • Ignora por completo las routing keys y enruta en función de los atributos de cabecera del mensaje que coincidan con los argumentos del binding
    • Distribuye los mensajes en round-robin entre todas las colas vinculadas
    • Enruta basándose en el tipo de contenido (content-type) del cuerpo del mensaje

15. 15. ¿Cuál es la diferencia conceptual entre una routing key y una binding key en RabbitMQ?

    • Son idénticas: ambos términos aluden a la misma cadena configurada por el productor
    • La routing key la establece el productor en el mensaje; la binding key se fija cuando se vincula una cola a una exchange
    • La binding key la fija el productor; la routing key se configura en la cola
    • Las routing keys solo se usan en direct exchanges; las binding keys solo en topic exchanges

16. 16. ¿Cómo se configura una Dead Letter Exchange (DLX) para una cola?

    • Estableciendo el argumento 'x-dead-letter-exchange' al declarar la cola
    • Publicando directamente hacia una exchange llamada 'dlx'
    • Habilitando el plugin rabbitmq_dlx
    • Configurando la propiedad 'dead-letter' en cada mensaje de forma individual

17. 17. ¿Cuál es la diferencia entre fijar el TTL de un mensaje por cola o por mensaje?

    • El TTL por cola aplica a todos los mensajes de dicha cola mediante x-message-ttl; el TTL por mensaje se define en la propiedad expiration del mensaje y puede variar entre ellos
    • El TTL por mensaje siempre tiene mayor prioridad y sobrescribe cualquier TTL de cola
    • El TTL por cola requiere un plugin; el TTL por mensaje es una característica nativa
    • No hay diferencia: ambos provocan un comportamiento idéntico en el broker

18. 18. ¿Cuál es la ventaja primordial de los publisher confirms frente a las transacciones AMQP (tx.select/tx.commit) en RabbitMQ?

    • Los publisher confirms son síncronos y bloquean el canal hasta que el broker confirma
    • Los publisher confirms proporcionan confirmaciones asíncronas y ligeras sin la pesada sobrecarga de two-phase commit de las transacciones
    • Las transacciones AMQP admiten confirmaciones por lotes; los publisher confirms no
    • Los publisher confirms solo están disponibles para quorum queues

19. 19. ¿Cuál es el propósito primordial del plugin Shovel en RabbitMQ?

    • Replicar colas entre nodos de un cluster para alta disponibilidad
    • Mover o copiar mensajes de forma fiable desde una cola/exchange de origen a una cola/exchange de destino, potencialmente entre brokers distintos
    • Exponer colas mediante una API REST HTTP
    • Comprimir las cargas útiles de los mensajes antes de almacenarlos

20. 20. ¿Cuál es la principal diferencia arquitectónica entre las quorum queues y las classic mirrored queues?

    • Las quorum queues emplean el consenso Raft para la replicación; las classic mirrored queues empleaban replicación maestro-espejo asíncrona
    • Las classic mirrored queues son más rápidas porque usan Raft; las quorum queues usan two-phase commit
    • Las quorum queues solo pueden existir en un único nodo; las mirrored queues abarcan todo el cluster
    • No hay diferencia: quorum queues es simplemente la nueva denominación de las mirrored queues

21. 21. ¿Cómo permite AMQP 0-9-1 múltiples flujos lógicos de comunicación sobre una sola conexión TCP en RabbitMQ?

    • Abriendo varios sockets TCP agrupados en un solo objeto de conexión
    • A través de canales: conexiones virtuales ligeras multiplexadas sobre una única conexión TCP
    • Utilizando multiplexación de streams HTTP/2 dentro del encapsulado AMQP
    • Codificando cada flujo lógico como un virtual host independiente

22. 22. ¿Qué función cumple el mecanismo channel.flow de AMQP 0-9-1?

    • Incrementa dinámicamente la ventana de prefetch cuando el consumidor está inactivo
    • Permite al broker o al cliente pausar/reanudar la entrega de mensajes en un canal para aplicar back-pressure
    • Migra un canal de una conexión TCP a otra sin interrupción
    • Vuelca a disco todos los mensajes pendientes del búfer interno de un canal

23. 23. ¿Cuál es el beneficio operativo primordial de declarar una cola como lazy queue?

    • Las lazy queues omiten el procesamiento de confirmaciones para incrementar el rendimiento
    • Las lazy queues escriben los mensajes directamente en disco según llegan en lugar de mantenerlos en memoria, reduciendo el consumo de RAM en colas extensas
    • Las lazy queues solo replican a disco cuando el nodo se reinicia
    • Las lazy queues posponen la comprobación de bindings hasta que se conecta un consumidor

24. 24. ¿Cuál es la principal diferencia arquitectónica entre el plugin Federation y el plugin Shovel?

    • Los enlaces de Federation son permanentes; los de Shovel son temporales y se borran tras un solo mensaje
    • Federation ofrece conexión de exchanges/colas débilmente acoplada entre brokers con nodos autónomos; Shovel es un transmisor básico punto a punto que precisa de acoplamiento directo
    • Shovel admite AMQP 1.0; Federation solo soporta AMQP 0-9-1
    • Son funcionalmente idénticos: Federation es solo el nombre renovado de Shovel

25. 25. ¿Qué logra el plugin consistent hash exchange que no puede hacer una direct o topic exchange convencional?

    • Enruta mensajes a exactamente una cola seleccionada por hash consistente de la routing key, balanceando la carga y manteniendo los mensajes con la misma clave en la misma cola
    • Replica mensajes en todas las colas vinculadas utilizando un mecanismo de deduplicación por hash
    • Calcula el hash del cuerpo del mensaje para verificar la integridad antes de enrutar
    • Garantiza la entrega equitativa (round-robin) entre colas sin importar la routing key

26. 26. En un cluster de RabbitMQ, ¿cuál es la diferencia funcional entre nodos de disco (disc nodes) y nodos de memoria (RAM nodes)?

    • Los nodos de disco persisten los metadados del broker (colas, exchanges, bindings, usuarios) en disco; los nodos de RAM guardan los metadatos solo en memoria para escrituras de menor latencia
    • Los nodos de RAM gestionan el enrutamiento de mensajes; los nodos de disco gestionan únicamente el almacenamiento persistente de mensajes
    • Los nodos de disco pueden alojar quorum queues; los nodos de RAM no
    • Son términos obsoletos: todos los nodos modernos de RabbitMQ son idénticos

27. 27. ¿Cómo emplean las quorum queues el algoritmo de consenso Raft para garantizar la seguridad de los datos?

    • Un mensaje se considera confirmado únicamente tras ser escrito por una mayoría (quórum) de réplicas, asegurando que no haya pérdida de datos incluso si falla una minoría de nodos
    • Raft se usa únicamente para la elección de líder; el almacenamiento de mensajes emplea un protocolo independiente de two-phase commit
    • Las quorum queues escriben en todas las réplicas sincrónicamente y exigen confirmación unánime
    • Raft asegura que los mensajes se dedupliquen en todos los nodos del cluster

28. 28. Cuando se configuran a la vez una política de cola y un argumento de declaración (ej.: x-message-ttl) para la misma clave, ¿cuál tiene prioridad en RabbitMQ?

    • Las políticas siempre prevalecen sobre los argumentos de declaración
    • Los argumentos de declaración siempre quedan supeditados a las políticas
    • Los argumentos de declaración (fijados al crear la cola) tienen prioridad sobre las políticas para la misma clave
    • Se combinan de forma aditiva: ninguno sobrescribe al otro

29. 29. ¿Qué par de métricas de gestión de RabbitMQ indica de forma más directa que los consumidores se están quedando rezagados respecto a los productores?

    • publish_rate y deliver_rate: cuando publish_rate supera sostenidamente a deliver_rate, messages_ready crecerá
    • memory_used y disk_free: un aumento de memory_used con descenso de disk_free refleja desfase del consumidor
    • connection_count y channel_count: demasiados canales indican acumulación de mensajes
    • node_uptime y gc_reclaim_rate: una actividad intensa del recolector de basura confirma desfase del consumidor

30. 30. ¿Cuál es el enfoque recomendado para el apagado ordenado (graceful shutdown) de un consumidor en RabbitMQ para evitar la pérdida de mensajes?

    • Terminar el proceso de inmediato: RabbitMQ reencolará automáticamente los mensajes sin confirmación
    • Cancelar la suscripción del consumidor, finalizar el procesamiento de todos los mensajes en curso, enviar ACKs o NACKs para cada uno y cerrar el canal y la conexión
    • Invocar basic.reject sobre todos los mensajes y cerrar la conexión TCP sin enviar la trama connection.close
    • Ajustar prefetch a 0 y aguardar a que el broker vacíe la cola antes de cerrar