Broker MQTT vs cola de mensajes es una distinción que confunde a muchos equipos, porque ambos son "message brokers" que se sitúan entre productores y consumidores. La diferencia está en la semántica de entrega: un broker MQTT copia cada mensaje a todos los suscriptores interesados en ese momento, mientras que una cola de mensajes retiene cada mensaje hasta que exactamente un consumidor se hace responsable de él. Esta guía explica ambos modelos, los compara con colas al estilo de RabbitMQ y SQS y muestra cuándo un broker MQTT en la nube es la pieza adecuada.
Dos modelos de entrega
Publish/subscribe basado en topics (MQTT). Un publicador envía un mensaje a un topic como plant1/line2/press4/temperature. El broker revisa todas las suscripciones actuales, encuentra aquellas cuyos filtros coinciden y entrega una copia a cada una. Si hay cinco servicios suscritos, salen cinco copias. Si no hay nadie suscrito, el mensaje se descarta, salvo que se retenga como último valor del topic o se encole en una sesión persistente. El trabajo del broker es enrutar, no almacenar. Para profundizar en el modelo, consulta el modelo publish/subscribe de MQTT.
Colas punto a punto (RabbitMQ, SQS y similares). Un productor envía un mensaje a una cola. El mensaje espera allí, de forma duradera, hasta que un consumidor lo recibe. Con varios consumidores en la misma cola, cada mensaje va solo a uno de ellos; compiten por el trabajo. El consumidor confirma tras procesarlo y, si se cae antes de confirmar, el mensaje vuelve a estar visible para otro consumidor. El trabajo de la cola es garantizar que alguien realice cada unidad de trabajo una vez.
En resumen: MQTT responde a "¿quién necesita saber esto?" y una cola responde a "¿quién va a hacer este trabajo?".
Broker MQTT vs cola de mensajes comparados
| Aspecto | Broker MQTT | Cola de mensajes (estilo RabbitMQ, SQS) |
|---|---|---|
| Entrega | Copia a cada suscriptor coincidente | Cada mensaje a un solo consumidor |
| Direccionamiento | Topics jerárquicos, comodines + y # |
Colas con nombre (más exchanges y bindings en RabbitMQ) |
| Mensaje creado sin consumidor | Se descarta, salvo que sea retained o se guarde para una sesión persistente | Se almacena hasta que se consume o expira |
| Almacenamiento | Último valor retenido por topic, colas de sesión por cliente | Colas duraderas, a menudo con retención larga |
| Confirmación | QoS 1 y 2 entre cliente y broker | Ack del consumidor tras procesar, reentrega si falla |
| Distribución de trabajo | Suscripciones compartidas en MQTT 5 | Consumidores en competencia nativos |
| Gestión de mensajes fallidos | No forma parte de MQTT | Función habitual (dead-letter queues y exchanges) |
| Orden | Por topic y por sesión de cliente | Por cola, con matices cuando hay reentregas |
| Modo de entrega | Push a los clientes conectados | Push (RabbitMQ) o pull/long poll (SQS) |
| Huella del cliente | Diminuta, funciona en microcontroladores | SDK de clase servidor |
| Presencia y estado | Keep alive, Last Will, retained messages | No aplica |
| Uso típico | Telemetría de dispositivos, comandos, estado en vivo, dashboards | Tareas en segundo plano, procesamiento de pedidos, microservicios desacoplados |
Dónde se solapan los modelos
La frontera no es del todo nítida, y eso explica parte de la confusión.
MQTT tiene dos funciones parecidas a una cola. Una sesión persistente hace que el broker encole los mensajes QoS 1 y 2 para un cliente mientras está desconectado; con MQTT 5 la acotas con un session expiry interval. Las suscripciones compartidas ($share/group/filter) permiten que varios clientes de un grupo se repartan los mensajes de un topic, de modo que cada mensaje llega a un solo miembro del grupo, que es exactamente el comportamiento de consumidores en competencia. Lee suscripciones compartidas en MQTT y sesión persistente en MQTT para más detalles.
Los sistemas de colas, a su vez, ofrecen pub/sub. Los exchanges fanout y topic de RabbitMQ copian un mensaje en varias colas, y los servicios en la nube combinan un topic de notificaciones con varias colas para la difusión. Pero cada suscriptor sigue necesitando su propia cola declarada de antemano.
Así que la verdadera pregunta no es qué funciones existen, sino qué modelo es el nativo. MQTT es difusión nativa con suscripciones ligeras y dinámicas; las colas son distribución de trabajo duradera nativa.
Comprueba la diferencia en dos minutos
Puedes ver la difusión en el servidor MQTT público gratuito con los clientes de mosquitto. Usa un prefijo único para no ver los mensajes de nadie más, y recuerda que es solo para pruebas, nunca para datos de producción.
PREFIX="connectmq/demo/$(openssl rand -hex 4)"
# Difusión: ejecuta esto en dos terminales, cada una con un client ID distinto
mosquitto_sub -h broker.connectmq.com -V mqttv5 -i fan-$RANDOM \
-t "$PREFIX/orders/new" -v
# Publica cinco mensajes, lo bastante despacio para el límite de frecuencia por cliente
for i in 1 2 3 4 5; do
mosquitto_pub -h broker.connectmq.com -V mqttv5 -i pub-$RANDOM -q 1 \
-t "$PREFIX/orders/new" -m "order $i"
sleep 0.5
done
Ambos suscriptores imprimen los cinco pedidos. Para el comportamiento tipo cola necesitas un plan de broker con suscripciones compartidas, como un broker Serverless (Paid) en ConnectMQ. Arranca dos workers con tus propias credenciales (cada worker necesita su propio client ID y las credenciales correspondientes del portal) y vuelve a publicar:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t '$share/workers/orders/new' -v
Los dos workers con suscripción compartida se reparten los mensajes, así que cada uno imprime solo algunos. Después detén ambos workers, vuelve a publicar y arráncalos de nuevo: los pedidos publicados mientras estaban desconectados se han perdido. Solo una sesión persistente los habría retenido, e incluso así solo para ese cliente concreto y dentro del session expiry interval. Ese es el hueco que cubre una cola de verdad.
Cuándo usar un broker MQTT
Un broker MQTT es la pieza adecuada cuando:
- Los productores son dispositivos. Sensores, gateways de PLC, vehículos, apps móviles y navegadores necesitan clientes pequeños y una gestión de conexiones tolerante.
- Muchos consumidores necesitan los mismos datos. Una lectura va a la vez a un dashboard, a un proceso que escribe en el historiador y a un servicio de alertas, y añadir un cuarto consumidor no requiere ningún cambio en el productor.
- El estado actual importa más que el historial. Los retained messages dan al instante el último valor conocido a cada nuevo suscriptor.
- Necesitas presencia. El keep alive y el Last Will te avisan cuando un dispositivo se desconecta.
- Necesitas enviar comandos a dispositivos concretos detrás de un NAT o en enlaces celulares.
Si los brokers son nuevos para ti, qué hace un broker MQTT cubre lo básico, y el tutorial de MQTT recorre los topics, la QoS y las sesiones.
Cuándo usar una cola de mensajes
Una cola es la pieza adecuada cuando:
- Cada mensaje es un trabajo que un único worker debe procesar exactamente una vez, como generar una factura o redimensionar una imagen.
- El trabajo debe sobrevivir a caídas largas de los consumidores, de horas o días.
- Necesitas reintentos y gestión de dead letters para los mensajes que fallan repetidamente.
- Los productores y consumidores son servicios backend en redes fiables.
Usar ambos a la vez
La mayoría de las plataformas IoT acaban teniendo ambos. Los dispositivos publican en un broker MQTT. Un servicio consumidor se suscribe, normalmente mediante una suscripción compartida para poder escalar horizontalmente, filtra el flujo hasta quedarse con los eventos que requieren procesamiento, por ejemplo "alarma activada" o "lote completado", y los encola como trabajos en RabbitMQ o SQS. La telemetría en vivo sigue llegando a los dashboards por MQTT, mientras que los flujos de negocio duraderos se ejecutan desde la cola. El artículo MQTT vs AMQP incluye un bridge funcional en Python.
Al elegir la parte MQTT, decide si operarla tú mismo o usar un broker MQTT en la nube. ConnectMQ es un broker MQTT gestionado con MQTT 3.1.1 y 5.0, TLS, retained messages, session expiry y, en el plan Serverless (Paid), suscripciones compartidas, además de aislamiento multi-tenant y cuotas por plan. Es un broker, no una cola: no tiene un bridge a colas integrado, así que tu servicio consumidor se encarga del traspaso, lo que mantiene la frontera explícita.
Empieza con ConnectMQ
Usa un broker MQTT para lo que mejor hace, difusión, estado en vivo y conectividad de dispositivos, y combínalo con una cola cuando necesites trabajos duraderos. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y prueba la demo de difusión y suscripción compartida anterior en tu propio broker privado.
Preguntas frecuentes
¿Es un broker MQTT una cola de mensajes?
No en el sentido clásico. Un broker MQTT enruta copias de cada mensaje a todos los suscriptores actuales, mientras que una cola almacena cada mensaje hasta que un consumidor lo procesa. MQTT tiene funciones parecidas a una cola, pero en esencia es pub/sub.
¿Puede MQTT garantizar que un mensaje se procese una sola vez?
QoS 2 garantiza una entrega exactamente una vez entre un cliente y el broker, no el procesamiento de extremo a extremo. Para procesar trabajos una sola vez, usa consumidores idempotentes o delega el trabajo en una cola de mensajes.
¿Qué pasa con los mensajes MQTT cuando no hay nadie suscrito?
Se descartan, salvo que el mensaje sea retained, en cuyo caso el broker lo guarda como último valor del topic, o que exista una sesión persistente para un suscriptor desconectado.
¿Debo usar RabbitMQ o un broker MQTT para dispositivos IoT?
Conecta los dispositivos a un broker MQTT, que está pensado para muchos clientes ligeros e intermitentes. Usa RabbitMQ detrás para las colas de trabajo del backend si tus flujos las necesitan.
