Pub/Sub de Redis

SocketIO4J utiliza el cliente Redisson para conectarse a un servidor Redis. También pueden admitirse backends compatibles con Redis alternativos como Valkey y DragonflyDB.

El RedissonPubSubEventStore proporciona un almacén de eventos para socketio4j usando Redis Pub/Sub. Permite el reenvío básico de eventos entre instancias de servidor mediante la transmisión de mensajes a través de canales de Redis, posibilitando operaciones de sala distribuidas y sincronización interna —pero sin garantías de durabilidad o reproducción.

Características clave

• Mensajería efímera por difusión — los eventos se entregan solo a suscriptores conectados actualmente

• Callbacks de oyente asíncronos — el despacho de Redis Pub/Sub se ejecuta fuera de los bucles de eventos de Netty

• Sincronización ligera entre múltiples nodos — configuración mínima cuando Redis ya está presente

• Enrutamiento por tema por evento — los tipos de evento se asignan directamente a canales de Pub/Sub

• Prevención de duplicados — filtra eventos que se originan en el mismo nodo (nodeId)

Cómo funciona

• publish0 envía el evento a un canal Redis Pub/Sub basado en el tipo de evento

• subscribe0 registra un oyente tipo-seguro en el canal correspondiente

• La entrega es solo push — los suscriptores deben estar en línea para recibir mensajes

• Al darse de baja o apagar, los oyentes de temas se eliminan pero los clientes de Redis permanecen abiertos

Modos

Modo	Comportamiento	Cuándo usar
MULTI_CHANNEL	Cada evento se asigna a su propio canal de Pub/Sub	Predeterminado; reduce la interferencia entre eventos
SINGLE_CHANNEL	Todos los eventos se enrutan a ALL_SINGLE_CHANNEL	Cuando se desea un ordenamiento completo de todos los tipos de evento

Ventajas

👍 Extremadamente simple de configurar 👍 Cero sobrecarga de persistencia — semántica de difusión pura 👍 Ideal para despliegues centrados en Redis o prototipos 👍 Funciona inmediatamente para comunicación básica entre múltiples nodos

Limitaciones

ℹ️ Los eventos son no persistidos — los suscriptores pierden eventos mientras están desconectados ℹ️ No hay mecanismo de reproducción — los nodos que se reconectan comienzan desde “ahora” ℹ️ Posibilidad de mensajes duplicados durante la reconexión ℹ️ El orden solo se aplica por canal; el orden global requiere SINGLE_CHANNEL modo

Garantía de entrega: Semántica de como máximo una vez. Entrega efímera y en el mejor esfuerzo — los oyentes deben tolerar la pérdida de mensajes y entregas fuera de orden.