Saltar al contenido

Lección 10 de 21 · Lectura y práctica

Implementar Pub/Sub para Notificaciones en Tiempo Real

Concepto claveRedis Pub/Sub (Publicador/Suscriptor) es un patrón de mensajería donde los emisores (publicadores) envían mensajes a canales sin conocer a los receptores (suscriptores), quienes reciben solo los mensajes de los.

Del concepto a la práctica

Taller de esta lección

Pub/Sub entrega un mensaje a los suscriptores activos del canal en el instante de publicación. No es una bandeja de entrada: si no hay receptores, el mensaje no queda esperando. Esta propiedad lo hace apropiado para una alerta visual efímera, no para una orden que deba procesarse.

Ejemplo resuelto

Un publicador envía a avisos:tienda el evento {"tipo":"stock","producto":7}. Dos suscriptores conectados reciben el mismo cuerpo. Un tercer cliente que se conecta después no recibe el evento anterior.

La entrega Pub/Sub es at-most-once y no incluye acknowledgement/replay: incluso un suscriptor conectado puede perder eventos ante desconexión o fallo. Separa conexión de suscripción según el cliente/protocolo para evitar mezclar comandos no permitidos en estado subscribed. Publicar un stock visual no demuestra que un pedido fue procesado ni que un pago se completó.

Pruébalo

  1. Abre dos suscriptores locales al mismo canal.

  2. Publica un evento con identificador de producto.

  3. Desconecta uno y publica otro evento.

  4. Reconecta y compara los mensajes recibidos.

Comprueba tu resultado

Error frecuente: usar Pub/Sub como cola de pagos. Corrige almacenando el trabajo en una cola y usando Pub/Sub solo para informar de cambios no durables. Resultado esperado: ambos receptores activos ven el primer evento, solo el conectado ve el segundo y el receptor reconectado no recupera mensajes pasados.

Diagrama de decisión con ramas Sí y No y un bucle que procesa cada elemento de una lista.
CursaloMapa de práctica
Cómo avanza un programa

Una condición decide qué camino ejecuta el programa. Un bucle repite una operación mientras queden elementos, y termina cuando la lista se agota. Separar ambas ideas ayuda a seguir el flujo y comprobar casos límite.

Ver la infografía en tamaño completo ↗

Concepto clave

Redis Pub/Sub (Publicador/Suscriptor) es un patrón de mensajería donde los emisores (publicadores) envían mensajes a canales sin conocer a los receptores (suscriptores), quienes reciben solo los mensajes de los canales a los que se han suscrito. Imagina un sistema de radio: las estaciones (publicadores) transmiten en frecuencias específicas (canales), y los oyentes (suscriptores) sintonizan esas frecuencias para escuchar. En backend, esto permite notificaciones en tiempo real, como actualizaciones de estado en aplicaciones web o alertas en sistemas de monitoreo.

La clave de Pub/Sub en Redis es su simplicidad y baja latencia: los mensajes se entregan inmediatamente a todos los suscriptores activos, sin persistencia por defecto (si un suscriptor está desconectado, pierde los mensajes). Esto lo hace ideal para escenarios donde la velocidad es prioritaria sobre la garantía de entrega, como notificaciones push en vivo o eventos de usuario en tiempo real. A diferencia de las colas (como Redis Lists o Streams), Pub/Sub no almacena mensajes; es puramente un mecanismo de difusión.

Cómo funciona en la práctica

Implementar Pub/Sub en Redis implica dos roles principales: el publicador que usa el comando PUBLISH y el suscriptor que usa SUBSCRIBE. Aquí un ejemplo paso a paso con datos simulados:

  1. Configuración inicial: Asegúrate de tener Redis corriendo (por ejemplo, en localhost:6379). Usa una biblioteca cliente como redis-py para Python.
  2. Crear un suscriptor: En un proceso o hilo, suscríbete a un canal llamado notificaciones. El código se bloquea esperando mensajes.
    import redis
    r = redis.Redis(host='localhost', port=6379)
    pubsub = r.pubsub()
    pubsub.subscribe('notificaciones')
    for message in pubsub.listen():
        if message['type'] == 'message':
            print(f"Recibido: {message['data'].decode()}")
  3. Publicar un mensaje: En otro proceso, publica un mensaje JSON al mismo canal.
    r.publish('notificaciones', '{"usuario": "alice", "evento": "login"}')
  4. Recibir en tiempo real: El suscriptor imprime inmediatamente el mensaje, demostrando la comunicación instantánea.

Puedes usar múltiples canales (por ejemplo, canal:admin y canal:usuario) para segmentar notificaciones, y los suscriptores pueden escuchar varios con SUBSCRIBE canal1 canal2.

Caso de estudio

Considera una plataforma de comercio electrónico que necesita notificar a los vendedores cuando hay nuevos pedidos. Usamos Redis Pub/Sub para enviar alertas en tiempo real sin recargar la página.

  • Arquitectura: El backend, tras procesar un pedido, publica un mensaje al canal pedidos:nuevos con datos como {"vendedor_id": 123, "pedido_id": 456, "monto": 99.99}.
  • Suscripción: La interfaz del vendedor (usando WebSockets conectados a un servicio backend) se suscribe a canales específicos (por ejemplo, pedidos:vendedor:123).
  • Resultado: Los vendedores ven notificaciones pop-up en segundos, mejorando la respuesta y experiencia de usuario. En pruebas, esto redujo el tiempo de atención de pedidos en un 40% comparado con polling HTTP.
En producción, monitorea el uso de memoria y conexiones: Pub/Sub puede consumir recursos si hay miles de suscriptores activos simultáneamente.

Errores comunes

  1. No manejar desconexiones: Si un suscriptor se desconecta de Redis, pierde todos los mensajes intermedios. Solución: Usa mecanismos de reconexión automática en el cliente y considera Redis Streams para persistencia si la entrega garantizada es crítica.
  2. Sobresuscribir canales: Suscribirse a muchos canales innecesarios aumenta la carga de red. Solución: Diseña una estrategia de canales minimalista (por ejemplo, por tipo de evento o usuario) y usa UNSUBSCRIBE cuando no se necesiten.
  3. Ignorar el rendimiento en escala: Pub/Sub puede ralentizarse con miles de mensajes por segundo. Solución: Prueba de carga con herramientas como redis-benchmark, y escala horizontal usando clusters Redis si es necesario.
  4. No sanitizar datos: Publicar mensajes sin validar puede llevar a inyección o corrupción. Solución: Siempre valida y serializa datos (por ejemplo, con JSON) antes de publicar.
  5. Confundir Pub/Sub con colas: Usar Pub/Sub para tareas asíncronas que requieren procesamiento único (como enviar emails) es un error. Solución: Para jobs, usa Redis Lists o Streams con workers.

Checklist de dominio

  • Puedo explicar la diferencia entre Pub/Sub y colas en Redis en menos de 30 segundos.
  • He implementado un publicador y suscriptor en un lenguaje como Python, Node.js o Java.
  • Sé cómo manejar desconexiones y errores en suscriptores con reconexión automática.
  • Puedo diseñar un esquema de canales para una app real (por ejemplo, notificaciones por usuario o evento).
  • He probado el rendimiento de Pub/Sub con al menos 100 mensajes/segundo en un entorno local.
  • Entiendo cuándo usar Pub/Sub (tiempo real) vs. Streams (persistencia) para casos de uso.
  • Puedo integrar Pub/Sub con WebSockets para notificaciones en frontend.

Construye un sistema de notificaciones en tiempo real para una app de chat

En este ejercicio, crearás un backend simple que use Redis Pub/Sub para enviar mensajes de chat en tiempo real entre usuarios. Sigue estos pasos:

  1. Configura el entorno: Instala Redis localmente (o usa un servicio como Redis Cloud) y una biblioteca cliente en tu lenguaje preferido (por ejemplo, redis-py para Python).
  2. Crea un publicador: Escribe un script que simule un usuario enviando un mensaje. Debe publicar a un canal llamado chat:general con un mensaje en formato JSON, por ejemplo: {"usuario": "Ana", "mensaje": "Hola a todos", "timestamp": 1633024800}.
  3. Crea un suscriptor: En otro terminal o proceso, suscríbete al canal chat:general y muestra los mensajes recibidos en consola, parseando el JSON para imprimir algo como: Ana: Hola a todos (10:00 AM).
  4. Extiende la funcionalidad: Modifica el sistema para soportar múltiples canales (por ejemplo, chat:soporte y chat:ventas). Agrega un comando que permita al suscriptor cambiar de canal dinámicamente.
  5. Prueba en tiempo real: Ejecuta el publicador y suscriptor simultáneamente, envía varios mensajes y verifica que se reciban instantáneamente. Mide la latencia con timestamps.

Entrega el código fuente y una breve explicación de cómo manejarías errores de conexión en producción.

Pistas
  • Usa el método pubsub() del cliente Redis para manejar suscripciones de forma eficiente.
  • Considera usar hilos o procesos separados para el suscriptor si tu app necesita hacer otras tareas.
  • Para el paso 4, investiga el comando PSUBSCRIBE para suscripciones con patrones si quieres más flexibilidad.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Sigue con Redis en Producción: Cache, Sesiones y Colas para Backend Engineers

Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.

Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.

01 / ELEGIR UNA RUTA

El próximo paso

Aprende IA mientras construyes algo que sí necesitas.

Empieza por el curso inicial o explora el catálogo para encontrar una práctica alineada con tu trabajo.