¿Qué significa compartir el Broker de Celery?

By julioperez Aug. 7, 2026, 3:50 p.m. celery Django python

Compartir el Broker de Celery

¿Qué es un Broker?

El broker es el intermediario entre una aplicación Django y los workers de Celery. Su función es recibir las tareas asíncronas y entregarlas a los workers para que las ejecuten.

Los brokers más utilizados son:

  • Redis
  • RabbitMQ

Flujo de trabajo

Django
   │
   │ Enviar tarea (.delay())
   ▼
Broker (Redis / RabbitMQ)
   │
   ▼
Worker de Celery
   │
   ▼
Ejecuta la tarea

¿Qué significa compartir el Broker?

Compartir el broker significa que varios proyectos utilizan el mismo servidor Redis o RabbitMQ para enviar y recibir tareas.

                 Redis
                    │
      ┌─────────────┼─────────────┐
      │             │             │
 Proyecto A    Proyecto B    Proyecto C

Esto evita tener un broker independiente para cada aplicación, reduciendo el consumo de recursos y simplificando la infraestructura.


¿Qué ocurre si no se configuran colas?

Si todos los proyectos utilizan la cola predeterminada (celery), las tareas pueden mezclarse.

Redis

Queue: celery

- enviar_factura
- generar_reporte
- enviar_email
- procesar_pago

La solución: utilizar colas (Queues)

Cada proyecto debe tener su propia cola.

CELERY_TASK_DEFAULT_QUEUE = "facturacion"
CELERY_TASK_DEFAULT_QUEUE = "inventario"
Redis

Queue: facturacion
- factura_1
- factura_2

Queue: inventario
- reporte_1
- reporte_2
celery -A facturacion worker -Q facturacion
celery -A inventario worker -Q inventario

Compartiendo Redis para varios servicios

Redis

Base 0 → Broker de Celery
Base 1 → Caché de Django
Base 2 → Django Channels
Base 3 → Sesiones
CELERY_BROKER_URL = "redis://localhost:6379/0"

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://localhost:6379/1",
    }
}

Ventajas de compartir el broker

  • Reduce el consumo de recursos.
  • Simplifica la infraestructura.
  • Permite escalar varios proyectos utilizando un solo broker.
  • Facilita la administración y el monitoreo.
  • Evita desplegar múltiples instancias de Redis o RabbitMQ.

¿Cuándo no es recomendable?

  • Cuando un proyecto genera una carga muy alta.
  • Cuando se requiere aislamiento entre clientes.
  • Cuando existen políticas de seguridad distintas.
  • Cuando se necesita mantenimiento independiente.

Ejemplo completo

api_pagos/
api_notificaciones/
CELERY_BROKER_URL = "redis://redis:6379/0"
CELERY_TASK_DEFAULT_QUEUE = "pagos"
CELERY_TASK_DEFAULT_QUEUE = "notificaciones"
celery -A api_pagos worker -Q pagos
celery -A api_notificaciones worker -Q notificaciones

Buenas prácticas

  • Una cola por proyecto o tipo de tarea.
  • Workers escuchando únicamente sus colas.
  • Monitorear el broker.
  • Separar proyectos de alta carga cuando sea necesario.
  • Usar nombres de colas descriptivos.

Conclusión

Compartir el broker de Celery permite que varios proyectos utilicen la misma infraestructura de mensajería mientras mantienen sus tareas aisladas mediante colas independientes, logrando una solución eficiente, escalable y fácil de administrar.


Compartir el broker entre proyectos (Ejemplo)

Una ventaja de compartir el broker es que un proyecto puede enviar tareas a otro sin necesidad de realizar llamadas HTTP o compartir lógica de negocio. Ambos proyectos solo necesitan tener acceso al mismo broker y conocer el nombre de la tarea.

Ejemplo

Supongamos que el proyecto AplicacionDjango1 necesita ejecutar una tarea definida en AplicacionDjango2.

# Proyecto AplicacionDjango1
from celery import Celery

app = Celery(
    "AplicacionDjango1",
    broker="redis://localhost:6379/0"
)  # La aplicación de Celery ya está configurada; solo se importa.

# Envía una tarea al proyecto AplicacionDjango2
app.send_task(
    "AplicacionDjango2.tasks.my_task_xd",
    args=[arg1, arg2]
)

¿Qué sucede internamente?

  1. AplicacionDjango1 envía un mensaje al broker (Redis).
  2. El broker almacena la tarea.
  3. El worker de AplicacionDjango2 escucha la cola correspondiente.
  4. AplicacionDjango2 recibe la tarea y ejecuta my_task_xd(arg1, arg2).
Proyecto AplicacionDjango1
      │
      │ send_task(...)
      ▼
 Redis (Broker compartido)
      │
      ▼
Worker de AplicacionDjango2
      │
      ▼
my_task_xd(arg1, arg2)

Nota: Para que esto funcione, ambos proyectos deben compartir el mismo broker y el worker de AplicacionDjango2 debe estar ejecutándose y escuchando la cola donde llega la tarea.