RabbitMQ

El message broker open-source más desplegado.

Service #message-broker#amqp#queue#messaging#pubsub

RabbitMQ es un message broker open-source rico en features que implementa AMQP 0-9-1, MQTT, STOMP y el protocolo RabbitMQ Streams. Es la elección por defecto para desacoplar microservicios, jobs en background fiables, fanout pub/sub y topologías de routing complejas. Pier despliega la imagen Docker oficial con la UI de management habilitada.

Desplegar con Pier

1 Abre el panel de Pier y haz clic en Add service.
2 Elige RabbitMQ en la lista de plantillas.
3 Elige la versión, asigna un nombre al servicio y Pier provisionará automáticamente el contenedor, el almacenamiento y los puertos.
4 Vincula un dominio si quieres HTTPS. Traefik genera el certificado de Let's Encrypt automáticamente.

¿Qué es RabbitMQ?

RabbitMQ es el message broker open-source más desplegado. Empezado en 2007 en Rabbit Technologies (después adquirido por Pivotal, ahora parte de Broadcom), implementa AMQP 0-9-1 como protocolo primario y añade MQTT, STOMP y RabbitMQ Streams vía plugins. Mozilla, Reddit, Cisco, NASA, AT&T y decenas de miles de otras organizaciones lo corren en producción.

El modelo de “broker inteligente” significa que RabbitMQ maneja routing, fanout, retries, TTLs, dead-lettering, prioridad — features que son server-side en RabbitMQ vs client-side en Kafka. Para colas de tareas, desacoplamiento de microservicios, delivery de webhooks y bridging IoT MQTT, RabbitMQ usualmente gana a Kafka en simplicidad y ergonomía.

Cómo lo despliega Pier

Pier usa la imagen Docker oficial rabbitmq con el tag :management que incluye el plugin de UI web. Puertos por defecto: 5672 (AMQP) y 15672 (UI de management). El volumen de datos se monta en /var/lib/rabbitmq — estado de colas, definiciones, almacenamiento de mensajes viven ahí.

Pier autogenera la contraseña del usuario admin. Para la UI de management, adjunta un dominio en el tab Domains de Pier y Traefik enruta tráfico al puerto 15672.

Connection string para apps cliente: amqp://admin:password@host:5672/.

Cuándo NO usar RabbitMQ

Para event streaming de alto throughput con necesidades de replay — Apache Kafka. Para pub/sub efímero sin requisito de durabilidad — Redis pub/sub. Para messaging cloud-native ultra-ligero — NATS. RabbitMQ es la elección por defecto cuando necesitas un broker rico en features con routing complejo, retries y madurez operativa.

Características clave

Multi-protocolo

AMQP 0-9-1 (primario), MQTT (IoT), STOMP (mensajería web) y RabbitMQ Streams (log estilo Kafka). Un broker, muchos clientes.

Tipos de exchange ricos

Direct, fanout, topic, headers, consistent-hash exchanges. Construye cualquier patrón de routing desde simple pub/sub hasta sharding por tenant.

UI de management + API HTTP

UI web para colas, exchanges, bindings, conexiones, channels, usuarios, vhosts. Cada acción de UI tiene equivalente en API HTTP — genial para automatización.

Colas quorum

Colas replicadas basadas en Raft para escenarios de alta disponibilidad. Sobrevive a fallos de nodos sin política de mirror manual.

TTL por mensaje y dead-letter exchanges

Soporte integrado para mensajes expirables, colas de retry y routing dead-letter. Sin plumbing externo de retry-with-backoff.

Patrones flexibles de consumer

Consumers competidores, consumers exclusivos, colas con prioridad, colas lazy (para backlogs enormes), notificaciones de cancelación de consumer.

Casos de uso

Procesamiento de jobs en background

Desacopla el manejo de requests HTTP del trabajo lento. Workers en cualquier lenguaje pulls de RabbitMQ — Celery (Python), Sidekiq (Ruby), Bull (Node), Hangfire (.NET).

Desacoplamiento de microservicios

El servicio A publica eventos; los servicios B y C consumen independientemente. Topic exchanges + cola por servicio te dejan añadir suscriptores sin cambiar publishers.

Fanout / event broadcasting fiable

Eventos de dominio broadcasteados a múltiples suscriptores — analítica, audit log, servicio de notificaciones, invalidador de caché — cada uno con su propia cola.

Broker MQTT para IoT

Los dispositivos publican telemetría vía MQTT; los servicios backend consumen vía AMQP. RabbitMQ puentea ambos protocolos sin fisuras.

Delivery de webhooks con retries

Webhooks entrantes → cola RabbitMQ → worker entrega a la URL definida por el usuario con exponential backoff (vía colas dead-letter de retry).

Ejemplos de código

Conectar desde Python (pika) python

import pika

conn = pika.BlockingConnection(
    pika.URLParameters("amqp://admin:password@rabbitmq:5672/")
)
ch = conn.channel()
ch.queue_declare(queue="emails", durable=True)
ch.basic_publish(
    exchange="",
    routing_key="emails",
    body='{"to": "[email protected]", "tpl": "welcome"}',
    properties=pika.BasicProperties(delivery_mode=2),
)

Consumir en Node.js (amqplib) javascript

import amqp from "amqplib";

const conn = await amqp.connect("amqp://admin:password@rabbitmq:5672/");
const ch = await conn.createChannel();
await ch.assertQueue("emails", { durable: true });
await ch.prefetch(10);
ch.consume("emails", (msg) => {
  const job = JSON.parse(msg.content.toString());
  sendEmail(job).then(() => ch.ack(msg));
});

Routing por topic exchange bash

# Declarar un topic exchange
rabbitmqadmin declare exchange name=events type=topic durable=true

# Servicio A binds a todos los eventos 'order.*'
rabbitmqadmin declare queue name=orders-svc-q durable=true
rabbitmqadmin declare binding source=events destination=orders-svc-q \
  routing_key="order.*"

Patrón dead-letter retry json

{
  "queue": "tasks",
  "arguments": {
    "x-dead-letter-exchange": "tasks-dlx",
    "x-dead-letter-routing-key": "retry"
  }
}

Comparativa

vs Apache Kafka	Kafka es un log append-only — alto throughput, replay-friendly, requiere Zookeeper o KRaft. RabbitMQ es un broker inteligente — routing flexible, throughput menor, operación más simple. Elige Kafka para event streaming a escala; RabbitMQ para colas de tareas y mensajería de microservicios.
vs Redis pub/sub y Streams	Redis es en memoria, simple, rápido. Redis Streams se acerca a semántica Kafka; Redis pub/sub es fire-and-forget. RabbitMQ gana en garantías de durabilidad, flexibilidad de routing y clustering.
vs NATS	NATS es messaging ultra-ligero basado en Go. Excelente para microservicios cloud-native. RabbitMQ tiene más features, más clientes, más madurez operativa.
vs Amazon SQS / Cloud Pub/Sub	Colas cloud gestionadas — simples, sin ops, vendor-locked. RabbitMQ es autohospedado con features ricas. Trade-off entre zero-ops y control total.

Preguntas frecuentes

¿Puerto por defecto y UI de management?

5672/tcp para AMQP, 15672/tcp para la UI de management. Pier expone ambos; adjunta un dominio para acceder a la UI vía HTTPS.

¿Credenciales por defecto?

Pier genera una contraseña fuerte para el usuario `admin` (RABBITMQ_DEFAULT_USER / RABBITMQ_DEFAULT_PASS). Visible en la página del servicio.

¿Persistencia?

Sí — Pier monta `/var/lib/rabbitmq` como volumen persistente. Los mensajes con `delivery_mode=2` (persistente) sobreviven a reinicios del broker cuando la cola es `durable`.

¿Clustering?

Los clusters de RabbitMQ necesitan Erlang cookie compartido + nodos descubribles por DNS — fuera del alcance de la plantilla single-container. Para HA, usa colas quorum en un solo nodo, o construye una plantilla multi-nodo custom.

¿Límites de memoria?

RabbitMQ usa `RABBITMQ_VM_MEMORY_HIGH_WATERMARK` (default 0.4 = 40% de RAM del sistema) para throttle a productores cuando la memoria baja. Tunea vía env si tu contenedor está limitado en memoria.

¿Qué versión despliega Pier?

Default `latest` (RabbitMQ 4.x). `3-management` y `4-management` son variantes fijadas que incluyen el plugin de UI de management.

¿Backups?

Para definiciones de colas + usuarios + policies — `rabbitmqctl export_definitions` a JSON, versiónalo en Git. Para datos de mensajes reales, típicamente no haces backup — diseña las colas como estado transitorio.

Servicios relacionados

Desplegar en tu VPS

Desplegar este servicio →